SIGada Conference

SIGada Conference

[Chris Miller]

Anyone care to post a summary of what went on at this conference.

Anything interesting ???

Chris Miller

Re: SIGada Conference

[Stephen Leake]

chrismiller677@hotmail.com (Chris Miller) writes:

> Anyone care to post a summary of what went on at this conference.
> 
> Anything interesting ???

The most interesting thing was that there are several companies making
money using Ada, and they are all growing :).

I've been more inspired to look into using SPARK to write solid code.

The Ada 200Y features sound fun, too; aggregates for limited types, a
solution for mutually recursive types, Java-style interfaces, no more
silent overloading when overriding was meant.

If you subscribe to Ada Letters, the proceedings should appear in a
few months :).

-- 
-- Stephe

Re: SIGada Conference

[Georg Bauhaus]

Stephen Leake <stephen_leake@acm.org> wrote:
: 
: The Ada 200Y features sound fun, too; aggregates for limited types, a
: solution for mutually recursive types, Java-style interfaces, no more
: silent overloading when overriding was meant.

Anything new about pre/post conditions?


-- Georg

Re: SIGada Conference

[Marin David Condic]

That can easily be misleading. Its possible that some companies are 
growing by getting a larger share of a shrinking pie. As some companies 
abandon Ada as a business venture, others pick up whatever share they 
may have had and show signs of "Growth" - but it doesn't imply Ada is 
necessarily doing well.

I'd like to see Ada get somewhere, but there needs to be a better metric 
than the business growth of some few companies. Jobs in Ada, new project 
starts in Ada, classes taught in Ada, etc. Any of those would be a beter 
metric - unless you could get total revenues for all companies doing Ada 
business (and even that would miss use of Ada in internal work by big 
companies like Boeing, Lockheed, etc.) In any event, its tough to get 
those metrics so we're still left with perceptions and best guesses. My 
perception is that Ada has been in general on the decline and had better 
do something to excite the world if it wants to be around with any real 
strength in another ten years.

MDC


Stephen Leake wrote:
> 
> The most interesting thing was that there are several companies making
> money using Ada, and they are all growing :).
> 



-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

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

     "Trying is the first step towards failure."
         --  Homer Simpson

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

RE: SIGada Conference

[amado.alves]

: The Ada 200Y features sound fun...
: ... Java-style interfaces...

I'm surprised this one is still being listed. It has been shown to be completely unnecessary.

Re: SIGada Conference

[Georg Bauhaus]

amado.alves <amado.alves@netcabo.pt> wrote:
: : The Ada 200Y features sound fun...
: : ... Java-style interfaces...
: 
: I'm surprised this one is still being listed. It has been shown to be completely unnecessary.

where?

Re: SIGada Conference

[Hyman Rosen]

Georg Bauhaus wrote:
> amado.alves <amado.alves@netcabo.pt> wrote:
> : : ... Java-style interfaces...
> : I'm surprised this one is still being listed. It has been shown to be completely unnecessary.
> where?

I expect this is just the usual "simulate MI with access discriminants"
bit that always comes up here. I think it can do everything except support
cross-casting.

Re: SIGada Conference

[Martin Dowie]

"amado.alves" <amado.alves@netcabo.pt> wrote in message
news:mailman.125.1071600001.31149.comp.lang.ada@ada-france.org...
: The Ada 200Y features sound fun...
: ... Java-style interfaces...

> I'm surprised this one is still being listed. It has been shown to be
completely unnecessary.

Sorry, I just don't buy this - if from only an IDE point of view.

Re: SIGada Conference

[Stephen Leake]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> Stephen Leake <stephen_leake@acm.org> wrote:
> : 
> : The Ada 200Y features sound fun, too; aggregates for limited types, a
> : solution for mutually recursive types, Java-style interfaces, no more
> : silent overloading when overriding was meant.
> 
> Anything new about pre/post conditions?

Nope. I think 'pragma Assert' will be standardized, but that's about it.



-- 
-- Stephe

Re: SIGada Conference

[Stephen Leake]

"amado.alves" <amado.alves@netcabo.pt> writes:

> : The Ada 200Y features sound fun...
> : ... Java-style interfaces...
> 
> I'm surprised this one is still being listed. It has been shown to
> be completely unnecessary.

Ok, I'll byte. "Shown" where?

Since the ARG people are _very_ smart, and _very_ motivated to
conserve implementors time, I suspect you are wrong :). Personally, I
think Java-style interfaces will let me do things I simply cannot do
now.

-- 
-- Stephe

Re: SIGada Conference

[Robert I. Eachus]

Stephen Leake wrote:

> Since the ARG people are _very_ smart, and _very_ motivated to
> conserve implementors time, I suspect you are wrong :). Personally, I
> think Java-style interfaces will let me do things I simply cannot do
> now.

Thanks for the compliment.  But I think everyone should be aware that we 
don't care whether or not a feature is "necessary."  What we really 
agonize about is how to make programming in Ada easier and make it more 
likely that Ada programs will satisfy all the "ilities."

The interfaces proposal allows a style of multiple inheritance that is 
currently not well supported in Ada.  Wonderful.  But the reason that it 
is a slam dunk that it will be in there, even if it does result in 
adding a new reserved word, is that it makes in much easier in many 
cases for a programmer to document what he is really trying to do.

It is possible to make fancy use of generics and dispatching so that you 
can have one specification matched by different bodies.  But the fact 
that different members of a class are handled in very different ways is 
hidden in the structure of the program.  Interfaces allow a programmer 
to say he is doing just that, and doing it intentionally.

For example you can have an indexed list type that calls different sort 
routines, hash table, radix sort, b-tree, etc. depending on the type of 
the index.  With interfaces the "documentation" of this occurs where the 
interface is implemented for a specific type of index, rather than where 
the index types are declared.  (And you don't need to manufacture a 
tagged parent type to make it work.)

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

RE: SIGada Conference

[amado.alves]

>>> : ... Java-style interfaces...
>> 
>> I'm surprised this one is still being listed. It has been shown to
>> be completely unnecessary.
>
> Ok, I'll byte. "Shown" where?

By *the* Ada guru J.-P. Rosen in Ada-Europe 2001 or 2002. And I seem to remember in the ARG discussions also, but I'll have to check.

> Personally, I
> think Java-style interfaces will let me do things I simply cannot do
> now.

That's what has been shown. That all those "things" can be done in Ada now. With either (yes) access discriminants which some say it's the golden nugget of Ada or, my favourite, formal packages. And mixins. And combinations thereof.

But please do come up with a new "thing" that cannot be done in Ada now.

"Java-style interfaces" is a poor man's multiple inheritance. I'd love to see fully fledged (linguistic) MI in Ada 2005, but *that* is too hard to define and implement. So I'm happy without it. But in that case I don't want the fake MI either.

RE: SIGada Conference

[amado.alves]

"It is possible to make fancy use of generics and dispatching so that you 
can have one specification matched by different bodies....
Interfaces allow a programmer 
to say he is doing just that, and doing it intentionally."

Formal packages provide that.

Anyway, I'm ok with interfaces per se. I just worry that they might push other (for me more interesting) additions off the list (e.g. container library) given the scarse revision resources.

/* Tangent but doubly related issue: increasing the power of generics viz. towards generic parameters would be also a more interesting addition to me. I mean to be able to pass a generic unit to a (mandatorily generic) unit. I came across many situations where this would be useful. */

Re: SIGada Conference

[Jean-Pierre Rosen]

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


"Hyman Rosen" <hyrosen@mail.com> a �crit dans le message de news:1071613043.278647@master.nyc.kbcfp.com...
> Georg Bauhaus wrote:
> > amado.alves <amado.alves@netcabo.pt> wrote:
> > : : ... Java-style interfaces...
> > : I'm surprised this one is still being listed. It has been shown to be completely unnecessary.
> > where?
>
> I expect this is just the usual "simulate MI with access discriminants"
> bit that always comes up here. I think it can do everything except support
> cross-casting.
>
It can. See my paper at http://www.adalog.fr/publicat/ada-interfaces.pdf

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

Re: SIGada Conference

[Hyman Rosen]

Jean-Pierre Rosen wrote:
> "Hyman Rosen" <hyrosen@mail.com> a �crit
>>I expect this is just the usual "simulate MI with access discriminants"
>>bit that always comes up here. I think it can do everything except support
>>cross-casting.
> 
> It can. See my paper at http://www.adalog.fr/publicat/ada-interfaces.pdf

Does this mean that you think it can support cross-casting,
or do you agree that it cannot? That is, in Java, I may have
two interfaces:
     interface IF_1 { }    interface IF_2 { }
and given an object of type IF_1, I may try to see if it is
also of type IF_2:
     boolean is_both(IF_1 o) { return o instanceof IF_2; }
and if it is, I can cross-cast:
     IF_2 as_IF_2(IF_1 o) { return is_both(o) ? (IF_2)o : null; }

Note that I can do this without any knowledge at all of the
existence of one or more parent types which implement both
interfaces. I don't think this can be done with the inner class/
access discriminant approach.

Re: SIGada Conference

[Robert C. Leif]

Since I am now the Chair of the Commercial Ada User's Group, CAUWEG, I
would like to add some comments form the view of commercial
utilization of Ada. Parenthetically, I hope that it is not the case
that I am both the Chair and the only member of CAUWEG.

There were 3 main threads at the meeting. The first was the obvious
success of SPARK including its use for real-time. The second was the
proposed object oriented additions to Ada; and the third was A# for
the .Net environment. There is an obvious difference between those who
are very interested in SPARK and those who are interested in object
oriented extensions to Ada. The emphasis in SPARK is provable,
efficient software which resides on the stack. The OO group wants to
create better OO capabilities in Ada.

Unfortunately, except for a talk by David Wheeler, there was no desire
from the ARG or WG9 or mention of "to make programming in Ada easier"
except for the OO paradigm. David Wheeler suggested adding a With and
Use Clause. This would allow one to write the package name only once.
Although I do not like the presence of a Use clause at the beginning
of a package; I, at least, favor efficient sinning. I would complement
this with a With and Renames Clause. With D renames A.B.C.D; Of even
greater significance is the omission of the GNAT 'img. The use of 'img
saves keyboarding and should make the sources easier to read.

I believe once SPARK includes the use of generics that can be
instantiated at compile time and class wide dispatching that occurs at
compile time, it will become a significant competitor to classic Ada.
Parenthetically, SPARK presently allows one to mix SPARK and Ada.

As for C#, I still believe that it is Ada's great hope. Unfortunately
since it is being developed in an academic setting, the Air Force
Academy; it has the characteristics of the university research product
that it is. A# is a brilliant innovation, but its lack of the final
touches needed for commercialization will greatly impede its present
use. The install is complex and to my dismay representation
specifications have not yet been implemented. I hope that some
commercial group takes over this product and delivers it for our use.

In a separate note, I will report on the XML section of the Birds of a
feather on APIs.

Bob Leif

"Robert I. Eachus" <rieachus@comcast.net> wrote in message news:<DaudnfwlSK39VkKiRVn-sQ@comcast.com>...
SNIP
> "Thanks for the compliment.  But I think everyone should be aware that we 
> don't care whether or not a feature is "necessary."  What we really 
> agonize about is how to make programming in Ada easier and make it more 
> likely that Ada programs will satisfy all the "ilities."
SNIP>

Other Ada Standards (was Re: SIGada Conference)

[Robert I. Eachus]

Robert C. Leif wrote:

> Unfortunately, except for a talk by David Wheeler, there was no desire
> from the ARG or WG9 or mention of "to make programming in Ada easier"
> except for the OO paradigm. David Wheeler suggested adding a With and
> Use Clause. This would allow one to write the package name only once.
> Although I do not like the presence of a Use clause at the beginning
> of a package; I, at least, favor efficient sinning. I would complement
> this with a With and Renames Clause. With D renames A.B.C.D; Of even
> greater significance is the omission of the GNAT 'img. The use of 'img
> saves keyboarding and should make the sources easier to read.

Hmmm.  Let me start by pointing out that the ARG is charged with 
maintaining the Ada standard, not the A# or SPARK standards.  Having 
said that, we do try to consider ALL users of Ada, not just those who 
use an OO style.  Several of the extensions/improvements being 
considered for Ada 0Y will wind up in Annex D or Annex H.  Alan Burns 
can probably do a better job of describing these changes and how the 
mesh with SPARK and the Ravenscar profile.

As for "with and use" I did comment on that proposal here. 
Unfortunately I probably spent more time explaining why "use implies 
with" can't work, than discussing how to allow a "with and use" context 
clause.  The problem with "with implies use" has nothing to do with most 
  cases where users would want to use "with and use".  The problem is 
that some use clauses, even in context clauses, name units that cannot 
be withed.  Adding "with and use" to the language would not be a 
problem, changing "use" to mean "with and use" is a non-starter.

Incidently, I thought that "use all", also discussed in that thread 
would be much more useful as a language extension.  But I'm getting far 
from the original topic.

I think you will find that many of the extensions currently being 
considered for Ada 0Y will be of use to all Ada programmers, not just 
those who do OO programming.  Look at the thread about adding interfaces 
here. Yes, interfaces will help people who want to use MI or certain 
other styles of OO programming.  But it also makes some idioms that have 
nothing to do with OO programming easier.  In fact, interfaces make 
implementing all sorts of design patterns easier.

If you do think that it would help to have a "real" A# ISO standard, 
suggest that to WG9, and they can submit a new work item (NWI) to JTC1. 
  My expectation would be that a new RG would be set up to address the 
NWI, and there would be some overlap with the ARG.  But it would be a 
separate standard, and a separate RG.  Same for SPARK, except that I 
think that NWI would be handed to the HRG.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Other Ada Standards (was Re: SIGada Conference)

[Robert A Duff]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> As for "with and use" I did comment on that proposal here. Unfortunately
> I probably spent more time explaining why "use implies with" can't work,
> than discussing how to allow a "with and use" context clause.  The
> problem with "with implies use" has nothing to do with most cases where
> users would want to use "with and use".  The problem is that some use
> clauses, even in context clauses, name units that cannot be withed.
> Adding "with and use" to the language would not be a problem, changing
> "use" to mean "with and use" is a non-starter.

I don't agree.  You could say that "use A.B.C;" in a context clause
implies a subset of "with A;", "with A.B;", and "with A.B.C;" -- just
the ones that happen to be library units.  Or, you could *require* that
they be library units, or be nested within already-mentioned library
units, if you think that makes the code more readable.  Either rule
would work, and be easily implementable.

Unfortunately, you can't just say that "use A.B.C;" is equivalent to
"with A.B.C; use A.B.C;", because A.B.C might not be a library unit.
Suppose A.B is a library package containing a nested package C.
Then "with A.B; use A.B.C;" is currently legal.  We can't say it's
equivalent to "with A.B; with A.B.C; use A.B.C;", because that would
be illegal, so the rule would be incompatible.

- Bob

Re: Other Ada Standards (was Re: SIGada Conference)

[Robert I. Eachus]

Robert A Duff wrote:

> I don't agree.  You could say that "use A.B.C;" in a context clause
> implies a subset of "with A;", "with A.B;", and "with A.B.C;" -- just
> the ones that happen to be library units.  Or, you could *require* that
> they be library units, or be nested within already-mentioned library
> units, if you think that makes the code more readable.  Either rule
> would work, and be easily implementable.

The problem is upward compatibility, and some fun for implementors.  The 
requirement you mention would not be upwardly compatible.  If "use 
A.B.C;" could mean "with A; with A.B; use A.B.C;" or "with A; use 
A.B.C;" or with A; with A.B; with A.B.C; use A.B.C;" or ...  things get 
real messy fast.  Note that even if the compiler can figure it out, the 
reader is going to be faced with the same challenge.

Allowing "with and use" in addition to current context clauses, and only 
if the name is meaningful according to the rules for with clauses seems 
so much simpler, and is easy on readers as well.  To me that makes the 
implicit with a non-starter.

> Unfortunately, you can't just say that "use A.B.C;" is equivalent to
> "with A.B.C; use A.B.C;", because A.B.C might not be a library unit.
> Suppose A.B is a library package containing a nested package C.
> Then "with A.B; use A.B.C;" is currently legal.  We can't say it's
> equivalent to "with A.B; with A.B.C; use A.B.C;", because that would
> be illegal, so the rule would be incompatible.

Yep.

However, did you follow the discussion of "use all A.B.C;"?  That would 
be like the with rule, meaning "use A; use A.B; use A.B.C;"  I don't 
know if I would use it much, but the parallel construction has a lot to 
recommend it.  Of course, if we add that use all, I'd love to also have 
use all Ada.*; or more likely use all Ada.Text_IO.*. ;-)

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Other Ada Standards (was Re: SIGada Conference)

[Russ]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccvfoec77b.fsf@shell01.TheWorld.com>...
> "Robert I. Eachus" <rieachus@comcast.net> writes:
> 
> > As for "with and use" I did comment on that proposal here. Unfortunately
> > I probably spent more time explaining why "use implies with" can't work,
> > than discussing how to allow a "with and use" context clause.  The
> > problem with "with implies use" has nothing to do with most cases where
> > users would want to use "with and use".  The problem is that some use
> > clauses, even in context clauses, name units that cannot be withed.
> > Adding "with and use" to the language would not be a problem, changing
> > "use" to mean "with and use" is a non-starter.
> 
> I don't agree.  You could say that "use A.B.C;" in a context clause
> implies a subset of "with A;", "with A.B;", and "with A.B.C;" -- just
> the ones that happen to be library units.  Or, you could *require* that
> they be library units, or be nested within already-mentioned library
> units, if you think that makes the code more readable.  Either rule
> would work, and be easily implementable.

And either rule would be preferable to requiring double naming of the
library units.

> Unfortunately, you can't just say that "use A.B.C;" is equivalent to
> "with A.B.C; use A.B.C;", because A.B.C might not be a library unit.
> Suppose A.B is a library package containing a nested package C.
> Then "with A.B; use A.B.C;" is currently legal.  We can't say it's
> equivalent to "with A.B; with A.B.C; use A.B.C;", because that would
> be illegal, so the rule would be incompatible.

And here's yet a third alternative that would be preferable to the
double naming clutter at the top of so many source files. Simple let
"use" imply "with", and if it doesn't compile, so what? The programmer
simply goes back and put in an explicit "with" that makes it work. No
big deal -- and no worse than the current situation.

So there are at least three alternatives that are preferable to the
status quo. If all three of them are rejected, then I think the Ada
community is shooting itself in the foot -- or somewhere else.

Re: Other Ada Standards (was Re: SIGada Conference)

[tmoran]

> ... and if it doesn't compile, so what? The programmer
> simply goes back and put in ...
   A fundamentally un-Ada way of approaching programming.  The Ada
programmer is supposed to *design*, based on *understanding*, not
just make tweaks to get around error messages.

Re: Other Ada Standards (was Re: SIGada Conference)

[Robert A Duff]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> Robert A Duff wrote:
> 
> > I don't agree.  You could say that "use A.B.C;" in a context clause
> > implies a subset of "with A;", "with A.B;", and "with A.B.C;" -- just
> > the ones that happen to be library units.  Or, you could *require* that
> > they be library units, or be nested within already-mentioned library
> > units, if you think that makes the code more readable.  Either rule
> > would work, and be easily implementable.
> 
> The problem is upward compatibility, and some fun for implementors.  The
> requirement you mention would not be upwardly compatible.

I don't see why not.  It seems upward compatible to me, and pretty
simple to implement.  And at least for the second rule I suggested,
I don't see how it could cause confusion for people reading the code.

> However, did you follow the discussion of "use all A.B.C;"?

No.

>...That would
> be like the with rule, meaning "use A; use A.B; use A.B.C;"  I don't
> know if I would use it much, but the parallel construction has a lot to
> recommend it.  Of course, if we add that use all, I'd love to also have
> use all Ada.*; or more likely use all Ada.Text_IO.*. ;-)

Shrug.  This seems like a feature with a totally different purpose.

- Bob

Re: Other Ada Standards (was Re: SIGada Conference)

[Robert A Duff]

18k11tm001@sneakemail.com (Russ) writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccvfoec77b.fsf@shell01.TheWorld.com>...
> > "Robert I. Eachus" <rieachus@comcast.net> writes:
> > 
> > > As for "with and use" I did comment on that proposal here. Unfortunately
> > > I probably spent more time explaining why "use implies with" can't work,
> > > than discussing how to allow a "with and use" context clause.  The
> > > problem with "with implies use" has nothing to do with most cases where
> > > users would want to use "with and use".  The problem is that some use
> > > clauses, even in context clauses, name units that cannot be withed.
> > > Adding "with and use" to the language would not be a problem, changing
> > > "use" to mean "with and use" is a non-starter.
> > 
> > I don't agree.  You could say that "use A.B.C;" in a context clause
> > implies a subset of "with A;", "with A.B;", and "with A.B.C;" -- just
> > the ones that happen to be library units.  Or, you could *require* that
> > they be library units, or be nested within already-mentioned library
> > units, if you think that makes the code more readable.  Either rule
> > would work, and be easily implementable.
> 
> And either rule would be preferable to requiring double naming of the
> library units.

I agree.

> > Unfortunately, you can't just say that "use A.B.C;" is equivalent to
> > "with A.B.C; use A.B.C;", because A.B.C might not be a library unit.
> > Suppose A.B is a library package containing a nested package C.
> > Then "with A.B; use A.B.C;" is currently legal.  We can't say it's
> > equivalent to "with A.B; with A.B.C; use A.B.C;", because that would
> > be illegal, so the rule would be incompatible.
> 
> And here's yet a third alternative that would be preferable to the
> double naming clutter at the top of so many source files. Simple let
> "use" imply "with", and if it doesn't compile, so what? The programmer
> simply goes back and put in an explicit "with" that makes it work. No
> big deal -- and no worse than the current situation.

I've no idea what you mean here.  What I was trying to say in the
paragraph you quoted above is:  If A.B is a library package, and
contains a nested package C, then "with A.B; use A.B.C;" is currently
legal.  If "use" implies "with", then that means
"with A.B; with A.B.C; use A.B.C;", which is illegal (and should remain
illegal -- you can only "with" library units).  There's no with_clause
you can add to make it legal.

> So there are at least three alternatives that are preferable to the
> status quo. If all three of them are rejected, then I think the Ada
> community is shooting itself in the foot -- or somewhere else.

As usual, Russ, you way overestimate the importance of such syntactic
sugar.  I agree with you that some such more-concise syntax would be an
improvement, and I disagree with those who say the sky would fall if we
allowed it.  But there are far more important changes (like allowing
initialization of limited objects), and *every* change has some cost.

- Bob

Re: Other Ada Standards (was Re: SIGada Conference)

[Russ]

18k11tm001@sneakemail.com (Russ) wrote in message news:<bebbba07.0312190051.5335ad9a@posting.google.com>...
> Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccvfoec77b.fsf@shell01.TheWorld.com>...
> > "Robert I. Eachus" <rieachus@comcast.net> writes:
> > 
> > > As for "with and use" I did comment on that proposal here. Unfortunately
> > > I probably spent more time explaining why "use implies with" can't work,
> > > than discussing how to allow a "with and use" context clause.  The
> > > problem with "with implies use" has nothing to do with most cases where
> > > users would want to use "with and use".  The problem is that some use
> > > clauses, even in context clauses, name units that cannot be withed.
> > > Adding "with and use" to the language would not be a problem, changing
> > > "use" to mean "with and use" is a non-starter.
> > 
> > I don't agree.  You could say that "use A.B.C;" in a context clause
> > implies a subset of "with A;", "with A.B;", and "with A.B.C;" -- just
> > the ones that happen to be library units.  Or, you could *require* that
> > they be library units, or be nested within already-mentioned library
> > units, if you think that makes the code more readable.  Either rule
> > would work, and be easily implementable.
> 
> And either rule would be preferable to requiring double naming of the
> library units.
> 
> > Unfortunately, you can't just say that "use A.B.C;" is equivalent to
> > "with A.B.C; use A.B.C;", because A.B.C might not be a library unit.
> > Suppose A.B is a library package containing a nested package C.
> > Then "with A.B; use A.B.C;" is currently legal.  We can't say it's
> > equivalent to "with A.B; with A.B.C; use A.B.C;", because that would
> > be illegal, so the rule would be incompatible.
> 
> And here's yet a third alternative that would be preferable to the
> double naming clutter at the top of so many source files. Simple let
> "use" imply "with", and if it doesn't compile, so what? The programmer
> simply goes back and put in an explicit "with" that makes it work. No
> big deal -- and no worse than the current situation.

Let me clarify this third alternative. I am suggesting that "use"
should imply "with" -- unless the implied "with" would not compile, in
which case the programmer would be responsible for putting in an
appropriate "with".

It occurred to me that this may be equivalent to Mr. Duff's third
alternative. If so, then please excuse my redundant redundancy.

> So there are at least three alternatives that are preferable to the
> status quo. If all three of them are rejected, then I think the Ada
> community is shooting itself in the foot -- or somewhere else.

Re: Other Ada Standards (was Re: SIGada Conference)

[Russ]

tmoran@acm.org wrote in message news:<ibGEb.603870$Fm2.547664@attbi_s04>...
> > ... and if it doesn't compile, so what? The programmer
> > simply goes back and put in ...
>    A fundamentally un-Ada way of approaching programming.  The Ada
> programmer is supposed to *design*, based on *understanding*, not
> just make tweaks to get around error messages.

And my suggested third alternative would not stop any programmer from
*designing* based on *understanding*. If he sees that the implied
"with" will not work, he simply puts in his own "with" that *will*
work. But if he forgets, the compiler will remind him, just as it will
remind him if he leaves out a semicolon. If he leaves out a semicolon,
does that mean that he is not *designing* based on *understanding*?

Re: Other Ada Standards (was Re: SIGada Conference)

[unknown]

18k11tm001@sneakemail.com (Russ) writes:

> Let me clarify this third alternative. I am suggesting that "use"
> should imply "with" -- unless the implied "with" would not compile, in
> which case the programmer would be responsible for putting in an
> appropriate "with".

OK, I think I get it.  Sorry for being obtuse earlier.

> It occurred to me that this may be equivalent to Mr. Duff's third
> alternative. If so, then please excuse my redundant redundancy.

I think you mean my *second* alternative (I gave only two).
Yes, I think we're talking about the same thing.
Perhaps I didn't explain it well.

It's the Department of Redundancy Department, I guess.  ;-)

- Bob

Re: Other Ada Standards (was Re: SIGada Conference)

[Russ]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccoeu4v1l2.fsf@shell01.TheWorld.com>...
> 18k11tm001@sneakemail.com (Russ) writes:
> 
> > Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccvfoec77b.fsf@shell01.TheWorld.com>...

> As usual, Russ, you way overestimate the importance of such syntactic

Perhaps, but I think many Ada experts *underestimate* it.

> sugar.  I agree with you that some such more-concise syntax would be an
> improvement, and I disagree with those who say the sky would fall if we
> allowed it.  But there are far more important changes (like allowing
> initialization of limited objects), and *every* change has some cost.

I agree. Yes, I'm sure there are more important changes to be made.

As I said in an earlier thread, I consider myself like a real estate
agent who tells a seller to clear the junk out of the front yard. No,
that's not as important as fixing the plumbing and electrical, but it
is by far the most cost-effective job the seller can do. If you want
to sell Ada, I think you would help your cause to take this
"superficial" and "cosmetic" issue seriously.

Re: Other Ada Standards (was Re: SIGada Conference)

[Nick Roberts]

Russ wrote:

> ... As I said in an earlier thread, I consider myself like a real estate
>  agent who tells a seller to clear the junk out of the front yard. No, 
> that's not as important as fixing the plumbing and electrical, but it is
>  by far the most cost-effective job the seller can do. If you want to 
> sell Ada, I think you would help your cause to take this "superficial" 
> and "cosmetic" issue seriously.

Hehe. I often feel that when introducing Ada to someone by presenting them
with a minimal Ada program, e.g.:

    procedure Hello is
       Put_Line("Hello World!");
    end;

it somewhat spoils the effect by adding "Oh, and then we have to put 'with
Ada.Text_IO;' in front of that. And then we have to put 'use Ada.Text_IO;'
as well. But Ada is /really/ simple. Honest."

Context clauses must be one of the most frequently used constructs in Ada.
I think they deserve attention for that reason.

I suggest that 'with and use A.B.C;' is used, and means /exactly/ the same
as 'with A.B.C; use A.B.C;' (it fails if 'with A.B.C;' fails). It's too
confusing for 'use A.B.C;' to imply 'with A.B;'. I fear a reviewer could be
sent into a spin searching for a library unit named 'A.B.C'.

I also like the idea of 'with X renames A.B.C;' a lot. I would love to be
able to write, for example:

    with ASB renames Ada.Strings.Bounded;
    procedure ... is
       ...
       package My_Strings is new ASB.Generic_Bounded_Length(100);

-- 
Nick Roberts
  __________________________________________________________
|  Fight Spam! Join EuroCAUCE: http://www.euro.cauce.org/  |
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: Other Ada Standards (was Re: SIGada Conference)

[Robert I. Eachus]

Nick Roberts wrote:

> Context clauses must be one of the most frequently used constructs in Ada.
> I think they deserve attention for that reason.

First, I'd like to point out that Bob Duff and I are relatively close in 
our positions on this.  The only issue with adding "with and use" in 
Ada0Y is whether it is worth the cost--and that is a close call.

With implies use can be made to work.  But I think the gymnastics 
required make it a non-starter.  Bob is willing to consider it. ;-)

But I think the relative cost of any with implies use variation is too 
high to make it into this revision.  Adding "with and use" to current 
context clauses should just be a bit of syntactic sugar for most compilers.

Anyone who argues that "with and use" is eight characters longer than 
"use" needs a better text editor.

> I suggest that 'with and use A.B.C;' is used, and means /exactly/ the same
> as 'with A.B.C; use A.B.C;' (it fails if 'with A.B.C;' fails). It's too
> confusing for 'use A.B.C;' to imply 'with A.B;'. I fear a reviewer could be
> sent into a spin searching for a library unit named 'A.B.C'.

I agree.  From the point of view of a reader, "with and use" is a slam 
dunk compared to use implies with.

> I also like the idea of 'with X renames A.B.C;' a lot. I would love to be
> able to write, for example:
> 
>    with ASB renames Ada.Strings.Bounded;
>    procedure ... is
>       ...
>       package My_Strings is new ASB.Generic_Bounded_Length(100);

Interesting idea.  I like it, but I would have to see what it looks like 
fleshed out.  Is the name Ada.Strings.Bounded also visible?  Can I say:

with and use ASB renames Ada.Strings.Bounded; --?

Incidently, you can currently write:

with Ada.Strings.Bounded
package ASB renames Ada.String.Bounded;

in your environment and be done with it.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Other Ada Standards (was Re: SIGada Conference)

[tmoran]

>    procedure Hello is
>       Put_Line("Hello World!");
>    end;
>
>it somewhat spoils the effect by adding "Oh, and then we have to put 'with
>Ada.Text_IO;' in front of that. And then we have to put 'use Ada.Text_IO;'
>as well. But Ada is /really/ simple. Honest."
  The "use..." is not needed if you fully qualify the Put_Line.
  And the "with..." corresponds to C's "#include stdio.h"
Things should be as simple as possible, but no simpler.

Re: Other Ada Standards (was Re: SIGada Conference)

[Russ]

"Robert I. Eachus" <rieachus@comcast.net> wrote in message news:<MbCdnfw97bXUF3miRVn-jA@comcast.com>...

> Anyone who argues that "with and use" is eight characters longer than 
> "use" needs a better text editor.

First, let me say that I think "with and use" is a big step forward
from double naming of library units.

The problem with it has nothing to do with eight extra characters, but
rather with the fact that it is grammatically awkward. You might say,
"use a hammer," but you would never say "with and use a hammer." I
think Ada's syntax is already awkward enough without this. I think
"with/use" is preferable, but I think "use" implies "with" is even
better.

Having said that, let me repeat that I consider "with and use"
preferable to double naming.

> > I suggest that 'with and use A.B.C;' is used, and means /exactly/ the same
> > as 'with A.B.C; use A.B.C;' (it fails if 'with A.B.C;' fails). It's too
> > confusing for 'use A.B.C;' to imply 'with A.B;'. I fear a reviewer could be
> > sent into a spin searching for a library unit named 'A.B.C'.
> 
> I agree.  From the point of view of a reader, "with and use" is a slam 
> dunk compared to use implies with.

I disagree. I think "use" implies "with" is fine, with the caveat that
it does so only if the "with" is legal. How often would this be an
issue in actual practice anyway? Not often, I suspect. Why let the
exception determine the rule?

Re: Other Ada Standards (was Re: SIGada Conference)

[Robert I. Eachus]

Dennis Lee Bieber wrote:

>         So create a new keyword, contraction of "with" and "use" --> "wise"
> 
>         What's so terrible, is that I'm not sure if I mean that as a joke...

Or within or whereas.  Not really joking either.  Once you realize that 
the current meaning of use has to be kept for use inside program units, 
and for odd upward compatibility cases, and that there is a large 
population of Ada programmers who often write with without use, then the 
  syntactic sugar of the proposal is just that, rather arbitrary syntax 
designed to look nice.  (I could of course suggest syntax that doesn't 
meet that criteria, but why?)

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Other Ada Standards (was Re: SIGada Conference)

[Warren W. Gay VE3WWG]

Nick Roberts wrote:

> Russ wrote:
>> ... As I said in an earlier thread, I consider myself like a real estate
>>  agent who tells a seller to clear the junk out of the front yard. No, 
>> that's not as important as fixing the plumbing and electrical, but it is
>>  by far the most cost-effective job the seller can do. If you want to 
>> sell Ada, I think you would help your cause to take this "superficial" 
>> and "cosmetic" issue seriously.
> 
> Hehe. I often feel that when introducing Ada to someone by presenting them
> with a minimal Ada program, e.g.:
> 
>    procedure Hello is
>       Put_Line("Hello World!");
>    end;
> 
> it somewhat spoils the effect by adding "Oh, and then we have to put 'with
> Ada.Text_IO;' in front of that. And then we have to put 'use Ada.Text_IO;'
> as well. But Ada is /really/ simple. Honest."

I would suggest that if a new student does not have
the stomach for the necessary with and use clauses,
then they won't last on the the longer haul anyway.

It is best to find this out, up front ;-)

You already know that Ada was not designed for use
in 3 line programs, but I don't think pandering
to students in this way is the best approach.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Other Ada Standards (was Re: SIGada Conference)

[Larry Hazel]

Robert I. Eachus wrote:

> Dennis Lee Bieber wrote:
> 
>>         So create a new keyword, contraction of "with" and "use" --> 
>> "wise"
>>
>>         What's so terrible, is that I'm not sure if I mean that as a 
>> joke...
> 
> 
> Or within or whereas.  Not really joking either.  Once you realize that 
> the current meaning of use has to be kept for use inside program units, 
> and for odd upward compatibility cases, and that there is a large 
> population of Ada programmers who often write with without use, then the 
>  syntactic sugar of the proposal is just that, rather arbitrary syntax 
> designed to look nice.  (I could of course suggest syntax that doesn't 
> meet that criteria, but why?)
> 
using or gimme :)

Re: Other Ada Standards (was Re: SIGada Conference)

[Warren W. Gay VE3WWG]

Russ wrote:

> "Robert I. Eachus" <rieachus@comcast.net> wrote in message news:<MbCdnfw97bXUF3miRVn-jA@comcast.com>...
>>Anyone who argues that "with and use" is eight characters longer than 
>>"use" needs a better text editor.
> 
> First, let me say that I think "with and use" is a big step forward
> from double naming of library units.
> 
> The problem with it has nothing to do with eight extra characters, but
> rather with the fact that it is grammatically awkward. You might say,
> "use a hammer," but you would never say "with and use a hammer." 

But in many contexts this immediately raises the question:

   "which hammer?"

(ie. X.Hammer or Y.Hammer?)

Thus the with-and-use approach often breeds conflict (apart
from this forum ;-)

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

come from joke (was Re: Other Ada Standards (was Re: SIGada Conference)

[Peter Hermann]

> So create a new keyword, contraction of "with" and "use" --> "wise"

does anybody know where to find that delicious joke about
those advanced syntax constructs like "come from" (complement to goto)
or "not procname;"(negating call to proc) etc. etc.    ?

Re: come from joke

[Samuel Tardieu]

>>>>> "Peter" == Peter Hermann <ica2ph@sinus.csv.ica.uni-stuttgart.de> writes:

>> So create a new keyword, contraction of "with" and "use" --> "wise"

Peter> does anybody know where to find that delicious joke about those
Peter> advanced syntax constructs like "come from" (complement to
Peter> goto) or "not procname;"(negating call to proc) etc. etc.  ?

"COME FROM" started as a joke but is no longer one: the Intercal
programming language uses this construct. See
http://www.catb.org/~esr/intercal/

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam

Re: come from joke (was Re: Other Ada Standards (was Re: SIGada Conference)

[Vinzent 'Gadget' Hoefler]

Peter Hermann wrote:

>does anybody know where to find that delicious joke about
>those advanced syntax constructs like "come from" (complement to goto)

Hmm. IIRC this is INTERCAL. Just checkout its RM at
<URL:http://www.muppetlabs.com/~breadbox/intercal-man/>. :)

Hmm, wasn't that the language where you have the no-op keyword PLEASE
and the matter how often you have to use to form a valid program text
is compiler-dependent or such...?

>or "not procname;"(negating call to proc) etc. etc.    ?

Not sure. Doesn't ring any bells. I doubt this is INTERCAL. Perhaps
it's "False"?

(Perhaps you'll find it somewhere here:
<URL:http://www.catseye.mb.ca/esoteric>,
<URL:http://members.tripod.com/rkusnery/weird.html> or
<URL:http://www.geocities.com/ResearchTriangle/Station/2266/tarpit/tarpit.html>).
Especially note the reference to "Magenta". ;)


Vinzent.

Re: come from joke (was Re: Other Ada Standards (was Re: SIGada Conference)

[Georg Bauhaus]

Peter Hermann <ica2ph@sinus.csv.ica.uni-stuttgart.de> wrote:
:> So create a new keyword, contraction of "with" and "use" --> "wise"
: 
: does anybody know where to find that delicious joke about
: those advanced syntax constructs like "come from" (complement to goto)
: or "not procname;"(negating call to proc) etc. etc.    ?

I think I've found it:

A LINGUISTIC CONTRIBUTION TO
GOTO- LESS PROGRAMMING
We don't know where to GOTO if we don't know where we've COME FROM.
This linguistic innovation lives up to all expectations
R. LAWRENCE CLARK*

http://doi.acm.org/10.1145/358027.358043
Reprinted courtesy of Datamation Magazine.
(C) by Technical Publishing Co., a Dun & Bradstreet Co., 1984.
All Rights Reserved.

*The author is indebted to G. E Groner and N.A. Palley for a valuable
discussion which took place in New Haven, Conn.

Re: come from joke (was Re: Other Ada Standards (was Re: SIGada Conference)

[Vinzent 'Gadget' Hoefler]

Georg Bauhaus wrote:

>http://doi.acm.org/10.1145/358027.358043

|Example:
|    10 J = 1
|    11 COME FROM 20
|    12 WRITE (6,40) J
|    STOP
|    13 COME FROM 10
|    20 J = J + 2
|    40 FORMAT (I4)
|
|Explanation:
|In this example, J is set to 1 by statement 10. Statement 13 then
|causes control to be passed to statement 20, which sets J to 3.
|Statement 11 then causes control to be passed to statement 12, which
|writes the current value of J. The STOP statement then terminates the
|program.
|
|[...]
|
|The author feels that the COME FROM will prove an invaluable
|contribution to the field of computer science. It is confidently
|predicted that this solution will be implemented in all future
|programming languages, and will be retrofitted into existing
|languages. Although it is clear that the COME FROM statement fulfills
|most of the requirements of the advocates of COTo-less programming, it
|remains for the practitioners of automatic programming to evaluate
|just how much this construct contributes to the development of
|automatic proofs of program correctness.
|Having at last put to rest the GOTO controversy, we now may enter the
|era of the COME FROM conundrum.

*looking at bottom of the page* Fortunately. The April issue.


Vinzent.

Re: come from joke (was Re: Other Ada Standards (was Re: SIGada Conference)

[Peter Hermann]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote:
> We don't know where to GOTO if we don't know where we've COME FROM.
> http://doi.acm.org/10.1145/358027.358043

yes, it was in the April issue.
thank you.

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

Re: Other Ada Standards (was Re: SIGada Conference)

[Chad R. Meiners]

"Larry Hazel" <lhhazel@otelco.net> wrote in message
news:kEGFb.292$kg.11855@eagle.america.net...
> using or gimme :)
>

How about

see Ada.Text_IO; -- ;-)

Procedure Hello_World is
begin
   Put_Line("Hello World.");
end Hello_World;

Re: come from joke

[Arthur Evans Jr]

Peter Hermann <ica2ph@sinus.csv.ica.uni-stuttgart.de> said:

> does anybody know where to find that delicious joke about those
> advanced syntax constructs like "come from" (complement to
> goto) or "not procname;"(negating call to proc) etc. etc.  ?
> 

and Samuel Tardieu <sam@rfc1149.net> wrote:

> "COME FROM" started as a joke but is no longer one: the Intercal
> programming language uses this construct. See
> http://www.catb.org/~esr/intercal/

The magazine Datamation, published AFAIR in the 60s or 70s, was at
the time the magazine to read for IT types. (The term Information
Technology hadn't yet been invented.) They published an article
suggesting this construct, probably in the April (fools) issue one
year. Great hack.

Art Evans

Re: come from joke

[Wes Groleau]

Samuel Tardieu wrote:
> "COME FROM" started as a joke but is no longer one: the Intercal
> programming language uses this construct. See
> http://www.catb.org/~esr/intercal/

But Intercal _is_ a joke, is it not?

-- 
Wes Groleau
Alive and Well
http://freepages.religions.rootsweb.com/~wgroleau/

Re: Other Ada Standards (was Re: SIGada Conference)

[Marin David Condic]

I'd bet that new reserved words are right out. Breaks upward 
compatibility of old code and all that. Although if one is looking for a 
variant on "with and use" that would be a good choice.

If it were possible to go adding new reserved words, how about:

library Ada ;

Giving the equivalent of a "with" for everything in the tree Ada... But 
then someone would want:

use library Ada ;

and want it to imply a with of everything under Ada as well as a use, 
and we're back to that whole thing... Now I've just thrown a turd in the 
punchbowl, havn't I? ;-)

I think its all a tempest in a teapot. While there might be some small 
convenience in some version of a "with and use", I don't see this as 
something that is either fundamentally broken, adding some new major and 
important capability or otherwise making the language significantly more 
attractive to the non-Ada crowd. The time spent implementing and 
verifying it could be better spent by adding new sublibraries to Ada 
that gave the user more leverage. Which would people rather have:

with and use My_Homegrown_Library_For_Tough_To_Get_Right_Math_Ops ;

or

with Ada.New_Math_Ops_Extensions_For_2005 ;
use Ada.New_Math_Ops_Extensions_For_2005 ;

Personally, I'd rather have to type two lines of code (over and over 
again, if necessary) than to develop my own matrix math, stats package, 
operations research math, etc.

Providing a bunch of pre-packaged math libraries with Ada would have the 
advantage of a) being relatively easy to specify and test, b) fairly 
straightforward to implement without hurting the compiler, and c) likely 
to make the language more attractive to people who have to do 
complicated math. Providing a "with and use" or "use implies with" is 
likely to a) be tricky to get right without breaking something, b) 
require fundamental changes to the compiler and c) not likely to make 
that many people thrilled to be using Ada. I'd say "no brainer" but 
that's just me. :-)

MDC


Chad R. Meiners wrote:
> 
> How about
> 
> see Ada.Text_IO; -- ;-)
> 
> Procedure Hello_World is
> begin
>    Put_Line("Hello World.");
> end Hello_World;
> 
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

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

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

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

Re: Other Ada Standards (was Re: SIGada Conference)

[Robert A Duff]

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

> I think its all a tempest in a teapot.

I agree with you there.

But you and others keep repeating this red herring:

> Personally, I'd rather have to type two lines of code (over and over
> again, if necessary) than to develop my own matrix math, stats package,
> operations research math, etc.

The issue has nothing to do with how much you have to type.  As some
wise person's signature (I forget who) says, that's your editor's job.
The reason the verbosity and redundancy of "with X; use X;" is bad
is that it's harder to read (than various proposed alternatives).

- Bob

Re: come from joke

[Simon Wright]

Samuel Tardieu <sam@rfc1149.net> writes:

> "COME FROM" started as a joke but is no longer one: the Intercal
> programming language uses this construct. See
> http://www.catb.org/~esr/intercal/

It is also the style favoured by use case writers, at least the ones I
have experience of (the claim is that the style is per Alan Cockburn,
but I've lost my copy ..)

-- 
Simon Wright                               100% Ada, no bugs.

Re: Other Ada Standards (was Re: SIGada Conference)

[Russ]

Marin David Condic <nobody@noplace.com> wrote in message news:<3FE991DD.5060301@noplace.com>...

> I think its all a tempest in a teapot. While there might be some small 
> convenience in some version of a "with and use", I don't see this as 
> something that is either fundamentally broken, adding some new major and 
> important capability or otherwise making the language significantly more 
> attractive to the non-Ada crowd. The time spent implementing and 
> verifying it could be better spent by adding new sublibraries to Ada 
> that gave the user more leverage. Which would people rather have:
> 
> with and use My_Homegrown_Library_For_Tough_To_Get_Right_Math_Ops ;
> 
> or
> 
> with Ada.New_Math_Ops_Extensions_For_2005 ;
> use Ada.New_Math_Ops_Extensions_For_2005 ;
> 
> Personally, I'd rather have to type two lines of code (over and over 
> again, if necessary) than to develop my own matrix math, stats package, 
> operations research math, etc.

Perhaps you could explain why you seem to think the two are mutually
exclusive, because I don't get it.

> Providing a bunch of pre-packaged math libraries with Ada would have the 
> advantage of a) being relatively easy to specify and test, b) fairly 
> straightforward to implement without hurting the compiler, and c) likely 
> to make the language more attractive to people who have to do 
> complicated math. Providing a "with and use" or "use implies with" is 
> likely to a) be tricky to get right without breaking something, b) 
> require fundamental changes to the compiler and c) not likely to make 
> that many people thrilled to be using Ada. I'd say "no brainer" but 
> that's just me. :-)

I remember back to discussions on this forum about the efficiency of
vector/matrix operations. Several folks insisted that Ada compilers
are (or could easily be) "smart" enough to avoid the extra temporary
objects and copying when using function-type operators such as "+". I
suspect that some of them did not really understand the the problem.

Now we swing over to the other extreme: something as trivial as "use"
implying "with" is somehow too "tricky". I just don't see how or why.
The rule could simply be that "use" implies "with" unless the implied
"with" wouldn't compile, in which case "use" would *not* imply "with",
and the programmer would be responsible for supplying the necessary
"with".

This rule would not break a single line of existing code, nor would it
force any programmer to write a single line of code any different than
if the rule were not in effect. And where is the difficulty for
compiler writers? They need to check the validity of any "with"
declaration anyway, don't they? What's the "tricky" part?

I can see one potential technical flaw. If the implied "with" is too
general, then I can understand why someone might oppose it. I don't
think this is the case, but I am not 100% sure because I am not an Ada
expert. Perhaps someone could clarify that. Would the implied "with"
"drag in" more than is minimally necessary to compile the program? If
not, I don't see any reasonable objection to it.

Just out of curiousity, approximately what percentage of implied
"with" declarations in actual practice wouldn't compile? Are we
talking 25% or 0.1%?

Re: Other Ada Standards (was Re: SIGada Conference)

[Robert A Duff]

18k11tm001@sneakemail.com (Russ) writes:

> Perhaps you could explain why you seem to think the two are mutually
> exclusive, because I don't get it.

Every change has some cost.  The ARG (mostly volunteers!) must write RM
wording, which is not trivial to get right, even for trivial-seeming
functionality.  But first they have to spend time arguing about what the
best rule is -- there are at least 3 viable possibilities I know of.
Compiler writers have to make changes to their compilers, and in many
cases, to other tools.

Therefore, there's only a certain amount of change that can be
tolerated, so Marin is correct to say that making *this* change would
tend to limit the chances of some other change.

This change is hard to evaluate: the cost is near zero, and the benefit
is also near zero, so the cost/benefit ratio is difficult to estimate.
I've seen many such cases over the years, and I'd guess they usually
lose.

> Now we swing over to the other extreme: something as trivial as "use"
> implying "with" is somehow too "tricky". I just don't see how or why.

I think Robert Eachus explained why.  I think he overestimates the
problem, but it's not "trivial".  And since the benefit is near zero,
it's probably not worth the trouble.  (I know you don't agree that the
benefit is near zero.  Junk in the front yard, and all that.)

Here's an example of why it might not be trivial to implement.  Most
compilers come with a tool to automatically figure out what needs to be
recompiled (and compilation order, which matters for some compilers).
This requires processing with_clauses, which have a very simple set of
visibility rules, that do not require looking "inside" of packages.
The new rule would require processing use_clauses as well, which *do*
require looking inside packages.  That's a mechanism that is obviously
supported by the compiler itself, but might be a whole new concept for
the recompilation tool.

> The rule could simply be that "use" implies "with" unless the implied
> "with" wouldn't compile, in which case "use" would *not* imply "with",
> and the programmer would be responsible for supplying the necessary
> "with".

It seems friendlier to me that it should imply the "appropriate" with.
There's always *some* with that it can imply, which is a prefix of the
use'd name.

> I can see one potential technical flaw. If the implied "with" is too
> general, then I can understand why someone might oppose it. I don't
> think this is the case, but I am not 100% sure because I am not an Ada
> expert. Perhaps someone could clarify that. Would the implied "with"
> "drag in" more than is minimally necessary to compile the program? If
> not, I don't see any reasonable objection to it.

No, it wouldn't "drag in" more.

> Just out of curiousity, approximately what percentage of implied
> "with" declarations in actual practice wouldn't compile? Are we
> talking 25% or 0.1%?

I'd guess about 1-to-2%, in the code I write.  That's a wild guess.
But as I said above, it's not that hard to avoid even this problem.

- Bob

Re: come from joke

[Stephane Richard]

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

it is to me :-)......like they said it's aim was to have no precedents...I
haven't seen any language that bad no...hehehe..

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com


"Wes Groleau" <groleau@freeshell.org> wrote in message
news:9cednZ9pco8dJnWi4p2dnA@gbronline.com...
> Samuel Tardieu wrote:
> > "COME FROM" started as a joke but is no longer one: the Intercal
> > programming language uses this construct. See
> > http://www.catb.org/~esr/intercal/
>
> But Intercal _is_ a joke, is it not?
>
> -- 
> Wes Groleau
> Alive and Well
> http://freepages.religions.rootsweb.com/~wgroleau/
>

Re: Other Ada Standards (was Re: SIGada Conference)

[Robert I. Eachus]

Robert A Duff wrote:

>>Now we swing over to the other extreme: something as trivial as "use"
>>implying "with" is somehow too "tricky". I just don't see how or why.
> 
> I think Robert Eachus explained why.  I think he overestimates the
> problem, but it's not "trivial".  And since the benefit is near zero,
> it's probably not worth the trouble.  (I know you don't agree that the
> benefit is near zero.  Junk in the front yard, and all that.)
> 
> Here's an example of why it might not be trivial to implement.  Most
> compilers come with a tool to automatically figure out what needs to be
> recompiled (and compilation order, which matters for some compilers).
> This requires processing with_clauses, which have a very simple set of
> visibility rules, that do not require looking "inside" of packages.
> The new rule would require processing use_clauses as well, which *do*
> require looking inside packages.  That's a mechanism that is obviously
> supported by the compiler itself, but might be a whole new concept for
> the recompilation tool.

Hmmm.  This is a good example of why "with and use" would be much easier 
to implement than "use implies with".  Those tools would still look for 
a with following a semicolon in a context clause, but they might have to 
skip over "and use."  That qualifies as trivial in my book.

And as Bob said, we can argue over how non-trivial "with implies use" 
would be for the ARG and compiler vendors.  There might be a neat 
solution that ties up all the loose ends.  In fact:

Bob Duff said:
> It seems friendlier to me that it should imply the "appropriate" with.
> There's always *some* with that it can imply, which is a prefix of the
> use'd name.

Which sounds like an improved version of "use implies with."  Personally 
I still think it would be harder on the reader than "with and use."

>>Just out of curiousity, approximately what percentage of implied
>>"with" declarations in actual practice wouldn't compile? Are we
>>talking 25% or 0.1%?

It depends.  The problem is that there are programming styles where they 
are common, and other styles where they are non-existant.  For example, 
I worked on one project where the utility packages were expected to have 
a nested Export package.  So on that project:

with Something; use Something.Export;

was very common, found on 90% or more of the bodies, and about 30% of 
the package specs.

> I'd guess about 1-to-2%, in the code I write.  That's a wild guess.
> But as I said above, it's not that hard to avoid even this problem.

Exactly.  It is so easy to avoid making it an issue that I can't see 
anyone on the ARG considering an upward incompatibility here.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Other Ada Standards (was Re: SIGada Conference)

[Marin David Condic]

I agree the typing is not a big deal. I disagree that its harder to read 
- in that I seldom put a "use" in the context clause anyway. (I put them 
in whatever subprogram declrative region really needs the package, or I 
use the dotted notation.)

But there are those who seem to want to piss and moan about how much 
clutter they have to type and look at in front of a library unit. I'll 
live with that in exchange for having more library units from which to 
choose. Don't go "fixing" compilers if the effort could be spent in 
building more standard libraries.

MDC

Robert A Duff wrote:
> 
> The issue has nothing to do with how much you have to type.  As some
> wise person's signature (I forget who) says, that's your editor's job.
> The reason the verbosity and redundancy of "with X; use X;" is bad
> is that it's harder to read (than various proposed alternatives).
> 
> - Bob


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

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

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

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

Re: Other Ada Standards (was Re: SIGada Conference)

[Marin David Condic]

The cost would *not* be near zero. Someone has to first work out all the 
legality rules and specify them in appropriate legalese for the ARM. 
Someone has to review and debate the new rules & test it against other 
rules to make sure it doesn't intercourse anything up. Someone has to go 
out and change every compiler that is currently being maintained, test 
it adequately to make sure it still works and then shepard it through 
validation. Someone has to write the validation suite - complete with 
cases that must be rejected by the compiler - not just ones that work. 
Someone has to argue that their compiler really did pass the suite with 
someone who has to argue that it didn't. Etc., etc., etc.

There is (as I'm sure you are aware) a whole lot of effort that goes 
into *any* language feature - no matter how seemingly trivial. Some of 
it is by volunteers - but that doesn't stop it from *costing* something. 
Volunteers will only "volunteer" for so much before they tell you to go 
pile sand. All these resources need to be used wisely.

That's why I think that given the cost of making some change like this, 
the money/time would better be spent on getting some feature that would 
make more of a difference to more people. Adding new library features 
doesn't involve compiler mods - just writing and validating the library. 
(Still a big job, but you didn't shake up a working compiler and have to 
prove it still works.) Hence I believe we'd get more useful stuff for 
the same input of effort.

MDC


Robert A Duff wrote:
> 
> This change is hard to evaluate: the cost is near zero, and the benefit
> is also near zero, so the cost/benefit ratio is difficult to estimate.
> I've seen many such cases over the years, and I'd guess they usually
> lose.


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

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

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

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

Re: Other Ada Standards (was Re: SIGada Conference)

[Russ]

Marin David Condic <nobody@noplace.com> wrote in message news:<3FEA5C82.8050309@noplace.com>...
> The cost would *not* be near zero. Someone has to first work out all the 
> legality rules and specify them in appropriate legalese for the ARM. 
> Someone has to review and debate the new rules & test it against other 
> rules to make sure it doesn't intercourse anything up. Someone has to go 
> out and change every compiler that is currently being maintained, test 
> it adequately to make sure it still works and then shepard it through 
> validation. Someone has to write the validation suite - complete with 
> cases that must be rejected by the compiler - not just ones that work. 
> Someone has to argue that their compiler really did pass the suite with 
> someone who has to argue that it didn't. Etc., etc., etc.

Whining like that over the smallest change makes really me wonder
about the future of Ada. If such a tiny change is so monumental, how
the hell are you guys going to handle significant changes?

I wonder if soldiers whine like that when they are imposed upon to
keep their barracks clean? After all, they have *much* more important
things to do -- like fight wars.

Re: Other Ada Standards (was Re: SIGada Conference)

[Georg Bauhaus]

Russ <18k11tm001@sneakemail.com> wrote:
: Marin David Condic <nobody@noplace.com> wrote in message news:<3FEA5C82.8050309@noplace.com>...
:> The cost would *not* be near zero.
 [explained]

: Whining like that over the smallest change makes really me wonder
: about the future of Ada. If such a tiny change is so monumental, how
: the hell are you guys going to handle significant changes?

I don't think, after reading what Robert Duff, Robert Eachus, and
Marin Condic have written, that we can say this is small/tiny,
that is big. On what basis? Because something _looks_ tiny to us
non-compiler writers?

On another account, we have had a discussion recently which you might
remember that there is a measure of software quality that uses the
number of units with'd. That number should not be high.
To me then this means that it is *much* more important to look
at how software is organized, and do this by looking at what is
with'd and what is use'd, and keeping that amount of program
text low by design, not by compressed syntax.
So I don't agree that it is junk in the frontyard because seen from
the perspective of unit dependence and unit use the verbosity looks
like a Good Thing to me.
So on the contrary, used properly, having the verbose solution
that Ada currently has might be an advantage.

: I wonder if soldiers whine like that when they are imposed upon to
: keep their barracks clean?

Certainly a clean place can be vitally important, from a medical
perspective. Still, I don't think this is a proper analogy.
With and use ...; instead of with ...; use ...; does not imply
clean software.
And removing dust and vermin is not the same thing as throwing
dust and vermin together into the same dust bin ;-)

If you allow a civilian to guess (and hope) that weapon control systems
(and other systems controlling dangerous devices) should be
expressively and unambigously labelled, foolproof, and possibly
*looking* redundant in order to avoid deadly explosive aberrations,
why not have character redundancy in the area of connecting software
modules by with; and use; the way it is done now?

-- Georg

Re: Other Ada Standards (was Re: SIGada Conference)

[Marin David Condic]

I don't know how difficult it would be in reality - to some extent that 
may be compiler-dependent. The point is, the cost isn't "Zero", the 
problem it purports to fix doesn't look like a problem - or at least a 
trivial problem and given the limited resources there are available for 
standards changes, we'd be better off dedicating those resources to some 
effort that is more significant. (Analogy: Are we rearranging the deck 
chairs on the Titanic? Maybe we'd be better off patching the big holes 
in the boat or helping the passengers get into the lifeboats.)

MDC

Georg Bauhaus wrote:
> 
> I don't think, after reading what Robert Duff, Robert Eachus, and
> Marin Condic have written, that we can say this is small/tiny,
> that is big. On what basis? Because something _looks_ tiny to us
> non-compiler writers?
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

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

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

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

Re: Other Ada Standards (was Re: SIGada Conference)

[Russ]

Marin David Condic <nobody@noplace.com> wrote in message news:<3FEB047A.1040100@noplace.com>...
> I don't know how difficult it would be in reality - to some extent that 
> may be compiler-dependent. The point is, the cost isn't "Zero", the 
> problem it purports to fix doesn't look like a problem - or at least a 
> trivial problem and given the limited resources there are available for 
> standards changes, we'd be better off dedicating those resources to some 
> effort that is more significant. (Analogy: Are we rearranging the deck 
> chairs on the Titanic? Maybe we'd be better off patching the big holes 
> in the boat or helping the passengers get into the lifeboats.)
> 
> MDC
> 
> Georg Bauhaus wrote:
> > 
> > I don't think, after reading what Robert Duff, Robert Eachus, and
> > Marin Condic have written, that we can say this is small/tiny,
> > that is big. On what basis? Because something _looks_ tiny to us
> > non-compiler writers?

OK, so letting "use" imply "with" may be non-trivial, and the folks
with the authority to bless it may not consider it worth the effort.
Fine. As previous discussion has pointed out, at least two other
options exist: "with and use" and "with/use". Now, I simply cannot see
how these options can be considered anything but *trivial* to
implement. For crying out loud, I could do it myself in 30 minutes,
and that includes 10 minutes to think about it and another 10 minutes
to test it!

Several people here have expressed a preference for "with and use". As
I wrote before, I think this is preferable to double naming, but it
reads funny. That's why I prefer "with/use". And no, the "/" is not an
"operator". Just think of "with/use" as a new keyword. It's the
simplest solution and it does the job perfectly well.

Whatever option you ultimately choose, please do yourselves a favor
and get rid of the double naming that clutters so many Ada source
files. When you pass Bob, do you say, "Hi, Bob. How are you, Bob?" or
do you say, "Hi, how are you, Bob?".

Re: come from joke

[John Woodruff]

"Stephane Richard" <stephane.richard@verizon.net> wrote in message news:<djqGb.171$tY5.150@nwrdny01.gnilink.net>...
> it is to me 

[...]

> >
> > But Intercal _is_ a joke, is it not?


Let's enjoy the Intercal joke a little more.  Especially since we all
know the significance of language names.

The intercal document states clearly "The full name of the compiler is
"Compiler Language With  No Pronounceable  Acronym,"  which  is,  for 
obvious  reasons, abbreviated "INTERCAL".

John

Re: Other Ada Standards (was Re: SIGada Conference)

[Georg Bauhaus]

Russ <18k11tm001@sneakemail.com> wrote:
: Marin David Condic <nobody@noplace.com> wrote in message news:<3FEB047A.1040100@noplace.com>...
:> I don't know how difficult it would be in reality - to some extent that 
:> may be compiler-dependent. The point is, the cost isn't "Zero", the 
:> problem it purports to fix doesn't look like a problem - or at least a 
:> trivial problem and given the limited resources there are available for 
:> standards changes, we'd be better off dedicating those resources to some 
:> effort that is more significant.

Yes. Good data structure libraries for example :-)

I'd rather read "with This.That;" and only go back to reading "use
This.That;" when I cannot resolve some identifier.  "with and use"
is just in the way then. Think of context clauses compared to
a table of contents or an index in a book.  Will "with and use"
really help guiding your eyes in finding the interesting units of
information if you have to read the following?

mmmm A.Nice.Lib;
mmmm mmm mmm Another.Kind;
mmmm Tremendous;
mmmm Yet.Another.One;
mmmm mmm mmm Zebras.Tedious;

As opposed to for example

mmmm A.Nice.Lib;
mmmm Another.Kind;       mmm Another.Kind;
mmmm Tremendous;
mmmm Yet.Another.One;
mmmm Zebras.Tedious;     mmm Zebras.Tedious;

Incidentally, with short package names there are no character
savings in the "with and use" case, because "and " may well need more
characters than the repeated package names plus ';' and ' '.

:> Georg Bauhaus wrote:
:> > 
:> > I don't think, after reading what Robert Duff, Robert Eachus, and
:> > Marin Condic have written, that we can say this is small/tiny,
:> > that is big. On what basis? Because something _looks_ tiny to us
:> > non-compiler writers?

: For crying out loud, I could do it myself in 30 minutes,
: and that includes 10 minutes to think about it and another 10 minutes
: to test it!

At least for the "implies" case, I couldn't even list the pieces of the
language definition that will have to be taken into consideration.
Congratulations :-) How about overloading, generics, use in bodies,
private library units, use inside subprograms, etc etc... Or do you
suggest that the number of rules in the language be increased
for special cases in order to cater for *less verbosity* in in Ada?

For the "with and use" case, what is your interpretation of
"with and use A.B;"
Is it "with A.B; use A.B;" or is it "with A; use A.B;"?
Which interpretation is to be chosen?

(And You seem to have access to a fast machine when it translates
a compiler and runs all tests within 10 minutes, in all required
configurations. Provided the tests have been written within the
30 minutes allocated for the implementation of the language change. :-)

: Whatever option you ultimately choose, please do yourselves a favor
: and get rid of the double naming that clutters so many Ada source
: files.

Could you give an account in percent of what, in your experience,
adds the most clutter? Like for example
1) spaghetti module design, implying a large number of context items
2) unfavourable formatting of context items
3) double naming
4) ...

: When you pass Bob, do you say, "Hi, Bob. How are you, Bob?" or
: do you say, "Hi, how are you, Bob?".

I don't think that this natural language greeting is a valid analogy
for a formal language "need specification". The phrase "with Bob;"
is different in meaning from "use Bob;" in Ada. But the two occurences
of "Bob" in the above greeting do not appear in different (natural
language) context, assuming that both "Hi" and "How are you"
provide conventional forms/parts of greeting.  (Even if "How are you"
is a question where "Hi" rarely is.) They both share rituality,
and besides they do not say anything about the visibility of
Bob's features at all. So what's the point?  Ada is not a natural
language, with and use have different uses in Ada than in English,
AFAICT.


-- Georg

Re: Other Ada Standards (was Re: SIGada Conference)

[Russ]

> :> Georg Bauhaus wrote:
> :> > 
> :> > I don't think, after reading what Robert Duff, Robert Eachus, and
> :> > Marin Condic have written, that we can say this is small/tiny,
> :> > that is big. On what basis? Because something _looks_ tiny to us
> :> > non-compiler writers?
>  
> : For crying out loud, I could do it myself in 30 minutes,
> : and that includes 10 minutes to think about it and another 10 minutes
> : to test it!
> 
> At least for the "implies" case, I couldn't even list the pieces of the
> language definition that will have to be taken into consideration.
> Congratulations :-) How about overloading, generics, use in bodies,
> private library units, use inside subprograms, etc etc... Or do you
> suggest that the number of rules in the language be increased
> for special cases in order to cater for *less verbosity* in in Ada?

I think you need to reread my post that you replied to here (the part
you cut out of the quote above). I meant that "with/use x;" would
simply be shorthand for "with x; use x;" I can write a Python script
to convert it to that in 30 minutes.

Yes, I realize that the reality is *slightly* harder than that because
a script preprocessor would be slightly inefficient, but you should
get the idea. If a compiler writer has a problem with a matter that
trivial, I think he is in the wrong business.

> For the "with and use" case, what is your interpretation of
> "with and use A.B;"
> Is it "with A.B; use A.B;" or is it "with A; use A.B;"?
> Which interpretation is to be chosen?

As I wrote in my original post, "with/use A.B;" would be exactly
equivalent to "with A.B; use A.B;" It's simple text substitution.
Nothing the slightest bit fancy or complicated. If the latter would
not compile, neither will the former. Please don't make it more
complicated than it is.

Re: Other Ada Standards (was Re: SIGada Conference)

[Georg Bauhaus]

Russ <18k11tm001@sneakemail.com> wrote:
 
: As I wrote in my original post, "with/use A.B;" would be exactly
: equivalent to "with A.B; use A.B;" It's simple text substitution.

Ah O.K., yes, preprocessing, not Ada.
Coming back to one of your analogies, "use hammer", let me replace
"hammer" with "potatoes". If you think of the way recipes are
written, "with potatoes;" and then "use potatoes"; seems like the
proper way to state things, namely in the "you need..." sections
and the "you do..." sections respectively? :-)

Using another analogy, a building site, you
"bring Tools;" from the shop and then "apply Tools;" at the site.
This looks like "with Tools; use Tools;" to me, to be understood
in contexts that do require separate instructions (shop: with,
site: use). But I still think analogies won't help.

And can a programming language be but grammatically awkward
if you measure its expressiveness by some (delibarately?) chosen
subset of natural language?


-- Georg

Re: Other Ada Standards (was Re: SIGada Conference)

[Dmitry A. Kazakov]

Georg Bauhaus wrote:

> For the "with and use" case, what is your interpretation of
> "with and use A.B;"
> Is it "with A.B; use A.B;" or is it "with A; use A.B;"?
> Which interpretation is to be chosen?

Just allow "with" everywhere "use" is allowed. Then "use A.B" could
literally imply "with A.B".

So:

package A is
   package B is
   ...
end A;

with A.B; -- This is OK, implies with A, as usual
package C is
   with A.B; -- This is also OK

BTW, this would give numerous addititional possibilities:

package X is
   -- public things

private
   with Something_Implementational.Not_To_Expose;

package Y is
   package Debug is -- I'll comment it out, later
      with Ada.Text_IO;
      ...
   end Debug;
   -- Sure that nothing from Ada.Text_IO leaks into
   -- other specifications of Y

I think it is worth to investigate the possible consequences of this
proposal.

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

Re: Other Ada Standards (was Re: SIGada Conference)

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: Georg Bauhaus wrote:
: 
:> For the "with and use" case, what is your interpretation of
:> "with and use A.B;"
:> Is it "with A.B; use A.B;" or is it "with A; use A.B;"?
:> Which interpretation is to be chosen?
: 
: Just allow "with" everywhere "use" is allowed. Then "use A.B" could
: literally imply "with A.B".

Hm.

if condition then     -- not Ada
  declare
    with X;
  begin
    ...;
  end;
else
  declare
    with Y;
  begin
    ...
  end;
end if;

What is the compiler to do?
 

: package X is
:   -- public things
: 
: private
:   with Something_Implementational.Not_To_Expose;
: 
: package Y is
:   package Debug is -- I'll comment it out, later
:      with Ada.Text_IO;
:      ...
:   end Debug;

why not

with Ada.Text_IO;
private package Y.Debug is

end Y.Debug;

Do you need the Debug things in further private definitions
after Debug?

: I think it is worth to investigate the possible consequences of this
: proposal.

We might end up with

package P is

   from Ada.Text_IO import Get_Line, Put_Line; --)

...
end P;

Re: Other Ada Standards (was Re: SIGada Conference)

[Marin David Condic]

Not many developers have experience with formal verification. They tend 
to see only the code change and not all the effort that needs to go into 
testing and verification the instant you flip a single bit in an image. 
I once had a customer ask me "Can you guarantee me that if you change a 
single word in memory that it won't blow up my billion dollar payload?" 
On reflection, I wasn't willing to bet a billion of his dollars on my 
*guess* that there wasn't some corner-case or unusual condition that 
might make a simple change of a constant blow up the rocket. That's why 
we test and that gets expensive.

A compiler is probably not so dangerous as a rocket engine control, but 
failure to pass validation because some "trivial" change had some subtle 
problem that the original programmer didn't understand is a) expensive 
and b) embarrassing to a company's reputation. That's why on important 
software there is no such thing as a "trivial" change.

MDC


Georg Bauhaus wrote:
> 
> (And You seem to have access to a fast machine when it translates
> a compiler and runs all tests within 10 minutes, in all required
> configurations. Provided the tests have been written within the
> 30 minutes allocated for the implementation of the language change. :-)
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

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

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

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

Re: Other Ada Standards (was Re: SIGada Conference)

[Robert A Duff]

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

> Just allow "with" everywhere "use" is allowed. Then "use A.B" could
> literally imply "with A.B".

That would defeat the whole purpose of with_clauses.  The point of
with's is that you can see a summary of the interconnections between
compilation units all in one spot, right up front.

The most important aspects of a software design are: what are the
pieces, and which pieces interact with which other pieces.  Scattering
this information all over the place is a bad idea, IMHO.

Why bother with with at all?  You might as well just say that any
reference to a name automatically imports that name, as necessary.
There are other languages that do something like that.

> So:
> 
> package A is
>    package B is
>    ...
> end A;
> 
> with A.B; -- This is OK, implies with A, as usual
> package C is
>    with A.B; -- This is also OK
> 
> BTW, this would give numerous addititional possibilities:
> 
> package X is
>    -- public things
> 
> private
>    with Something_Implementational.Not_To_Expose;

It is indeed unfortunate that you can't have with's that apply only to
the private part.  IMHO, the language would be better if the with's
appeared *inside* the package, either at the start of the visible part,
or the start of the private part, or the start of the body.  But I want
them together, up front (for each of these parts) -- not scattered all
over.

By the way, I think there's an AI allowing with's to apply to the
private part.  Something like "with private X" or "private with X".
It still has to go outside, *before* the text of the package spec, 
which is unfortunate.  My suggestion of putting the with's inside is way
too big a change to consider seriously.

- Bob

Re: Other Ada Standards (was Re: SIGada Conference)

[Robert I. Eachus]

Marin David Condic wrote:

> A compiler is probably not so dangerous as a rocket engine control, but 
> failure to pass validation because some "trivial" change had some subtle 
> problem that the original programmer didn't understand is a) expensive 
> and b) embarrassing to a company's reputation. That's why on important 
> software there is no such thing as a "trivial" change.

I'm a lot less forgiving than you are.  On the first major compiler 
project I worked on, there was a development version of the compiler, 
and a "base" version.  There was a 20 minute validation suite you had to 
pass to add anything to the development version, and the base version 
was owned by a daemon process that bound the development version at 
midnight, then ran the complete regression test suite on it.  If there 
were no errors, this became the new base version.  If there were errors 
repeat as needed.

There was one individual who didn't like to rerun the 20 minute 
validation suite if he found a "small" glitch.  The third time he did 
this, I went to my boss (the department head) and wanted to fire him.  I 
was told that a layoff was coming, and this guy would be the sacrificial 
goat for the department.

I mean, it didn't even require him to hang around for the test to 
complete.  The normal--I'd like to say only, but it was possible to 
circumvent it if several developers had to submit changes as a 
group--means of updating the development version was to submit a 
directory with the new source units using a script.  Twenty minutes 
later (or longer if the system was loaded down), you would get either an 
e-mail telling you the submission succeeded, or a list of the tests that 
failed, with error messages, either compile-time or run-time.  (There 
was also a option to run the whole regression suite.  I almost always 
chose this option if no one was "waiting" for my changes to submit 
something else.)

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Other Ada Standards (was Re: SIGada Conference)

[Russ]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:<bsjpps$dab6p$1@ID-77047.news.uni-berlin.de>...
> Georg Bauhaus wrote:
> 
> > For the "with and use" case, what is your interpretation of
> > "with and use A.B;"
> > Is it "with A.B; use A.B;" or is it "with A; use A.B;"?
> > Which interpretation is to be chosen?
> 
> Just allow "with" everywhere "use" is allowed. Then "use A.B" could
> literally imply "with A.B".

Correct me if I am wrong, but I don't think you meant exactly what you
wrote. I think you meant that "with" should never choke on an argument
that "use" would not choke on.

If I understand you correctly, I think that's an excellent proposal.
It would eliminate an annoying technicality that prevents
simplification of context declarations.

Re: Other Ada Standards (was Re: SIGada Conference)

[Robert I. Eachus]

Russ wrote:

> If I understand you correctly, I think that's an excellent proposal.
> It would eliminate an annoying technicality that prevents
> simplification of context declarations.

Some people don't agree with you that it is an "annoying technicality." 
Do I sometimes use the feature? Yes.  Often?  No.  But there are times 
when you need it, and there is no reasonable workaround.  (The type or 
types of the parameters of the compilation unit you are creating are 
declared in a nested package, or some of the operations you need for the 
initial values.)  There are other people who almost never write a use 
clause that could be replaced by a with clause.

On a difficulty scale, adding a feature to the language is easier than 
changing a feature, and most difficult of all is removing or replacing a 
feature.  (Not that we haven't done it--see Annex J.)

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Other Ada Standards (was Re: SIGada Conference)

[Russ]

Marin David Condic <nobody@noplace.com> wrote in message news:<3FED9286.5050800@noplace.com>...

> A compiler is probably not so dangerous as a rocket engine control, but 
> failure to pass validation because some "trivial" change had some subtle 
> problem that the original programmer didn't understand is a) expensive 
> and b) embarrassing to a company's reputation. That's why on important 
> software there is no such thing as a "trivial" change.

Well, I've been involved with important software, and I've seen many
trivial changes to it. Of course even trivial changes need to be done
carefully, and of course even trivial changes should be tested, and of
course trivial changes should not be done at the last minute before an
important release -- but that does not mean they are not trivial.
Changing an output format from three to four significant digits, for
example, is trivial by any reasonable standard. Hence your
lofty-sounding pronouncement above is nonsense.

I fully understand the need to be careful with software, but there is
a point where you can be too careful. If a change can be implemented
(albeit inefficiently) in 30 minutes by one person, and if avoiding
the change will inconvenience programmers and clutter code for the
next ten years, you're past that point. For Pete's sake, don't be
paralyzed with fear over nothing.

Re: Other Ada Standards (was Re: SIGada Conference)

[Russ]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> wrote in message news:<bsjppt$9o7$1@a1-hrz.uni-duisburg.de>...
> Russ <18k11tm001@sneakemail.com> wrote:
>  
> : As I wrote in my original post, "with/use A.B;" would be exactly
> : equivalent to "with A.B; use A.B;" It's simple text substitution.
> 
> Ah O.K., yes, preprocessing, not Ada.
> Coming back to one of your analogies, "use hammer", let me replace
> "hammer" with "potatoes". If you think of the way recipes are
> written, "with potatoes;" and then "use potatoes"; seems like the
> proper way to state things, namely in the "you need..." sections
> and the "you do..." sections respectively? :-)

But you don't say "with and use potatoes". The problem is that "with"
is a preposition and "use" is a verb, and the two types are never
combined with "and."

> Using another analogy, a building site, you
> "bring Tools;" from the shop and then "apply Tools;" at the site.
> This looks like "with Tools; use Tools;" to me, to be understood
> in contexts that do require separate instructions (shop: with,
> site: use). But I still think analogies won't help.

Again, you don't say, "with and use tools".

> And can a programming language be but grammatically awkward
> if you measure its expressiveness by some (delibarately?) chosen
> subset of natural language?

No, a programming language is not required to use grammatically
correct English, but that is not my point. All I am suggesting is that
Ada should avoid an awkward grammatical construct if a better
alternative is available. I think "with/use" is less awkward, and it
also happens to be shorter.

Re: Other Ada Standards (was Re: SIGada Conference)

[Dmitry A. Kazakov]

Russ wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:<bsjpps$dab6p$1@ID-77047.news.uni-berlin.de>...
>> Georg Bauhaus wrote:
>> 
>> > For the "with and use" case, what is your interpretation of
>> > "with and use A.B;"
>> > Is it "with A.B; use A.B;" or is it "with A; use A.B;"?
>> > Which interpretation is to be chosen?
>> 
>> Just allow "with" everywhere "use" is allowed. Then "use A.B" could
>> literally imply "with A.B".
> 
> Correct me if I am wrong, but I don't think you meant exactly what you
> wrote. I think you meant that "with" should never choke on an argument
> that "use" would not choke on.

Yep.

> If I understand you correctly, I think that's an excellent proposal.
> It would eliminate an annoying technicality that prevents
> simplification of context declarations.

Well, one can never know all the consequences of a proposal...

With/use issue is rather a cosmetic one. It might be very important for
language promoting, though for those who are using Ada on daily basis, it
is uninteresting, yet. Another very important cosmetic thing, (Robert
Eachus and me mentioned it before) could be an ability to bundle a set of
with's and use's in one package with then could be with-ed / used-ed
instead.

And these cosmetic things are about

- information hiding,
- refactoring,
- reuse

of declarations. Isn't it more than just an issue of training a text editor?

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

Re: Other Ada Standards (was Re: SIGada Conference)

[Dmitry A. Kazakov]

Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> : Georg Bauhaus wrote:
> : 
> :> For the "with and use" case, what is your interpretation of
> :> "with and use A.B;"
> :> Is it "with A.B; use A.B;" or is it "with A; use A.B;"?
> :> Which interpretation is to be chosen?
> : 
> : Just allow "with" everywhere "use" is allowed. Then "use A.B" could
> : literally imply "with A.B".
> 
> Hm.
> 
> if condition then     -- not Ada
>   declare
>     with X;
>   begin
>     ...;
>   end;
> else
>   declare
>     with Y;
>   begin
>     ...
>   end;
> end if;
> 
> What is the compiler to do?

Where is any problem? Exactly this is already allowed! Consider:

   procedure With_X is separate;
   procedure With_Y is separate;
   ...
   if Condition then -- Now this is Ada
      With_X;
   else
      With_Y;
   end if;

with X;
separate (...) procedure With_X is ... end With_X;

with X;
separate (...) procedure With_Y is ... end With_Y;

> : package X is
> :   -- public things
> : 
> : private
> :   with Something_Implementational.Not_To_Expose;
> : 
> : package Y is
> :   package Debug is -- I'll comment it out, later
> :      with Ada.Text_IO;
> :      ...
> :   end Debug;
> 
> why not
> 
> with Ada.Text_IO;
> private package Y.Debug is
> 
> end Y.Debug;
> 
> Do you need the Debug things in further private definitions
> after Debug?

I wished to illustrate a use of with in a nested declarative region.
Technically one could always make a child package out of it. Though, not
always, a child of a generic package is also generic...

> : I think it is worth to investigate the possible consequences of this
> : proposal.
> 
> We might end up with
> 
> package P is
> 
>    from Ada.Text_IO import Get_Line, Put_Line; --)
> 
> ...
> end P;

Or with getting rid of with clauses at all, as Robert Duff mentioned in
passing! I never liked them. How about that?

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

Re: Other Ada Standards (was Re: SIGada Conference)

[Dmitry A. Kazakov]

Robert A Duff wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> Just allow "with" everywhere "use" is allowed. Then "use A.B" could
>> literally imply "with A.B".
> 
> That would defeat the whole purpose of with_clauses.  The point of
> with's is that you can see a summary of the interconnections between
> compilation units all in one spot, right up front.

Should a reader see these interconnections? Couldn't we bring the famous "it
is a question of a good IDE" argument here?

> The most important aspects of a software design are: what are the
> pieces, and which pieces interact with which other pieces.  Scattering
> this information all over the place is a bad idea, IMHO.

Again, true. But it is not compilation units which interacts, but rather 
smaller objects.

> Why bother with with at all?  You might as well just say that any
> reference to a name automatically imports that name, as necessary.
> There are other languages that do something like that.

Absolutely. I think that the compilers are enough mature to go without with.
Can we go so far? [with-ing generic children is really boring] Will
implying of "with" be backward compatible?

>> So:
>> 
>> package A is
>>    package B is
>>    ...
>> end A;
>> 
>> with A.B; -- This is OK, implies with A, as usual
>> package C is
>>    with A.B; -- This is also OK
>> 
>> BTW, this would give numerous addititional possibilities:
>> 
>> package X is
>>    -- public things
>> 
>> private
>>    with Something_Implementational.Not_To_Expose;
> 
> It is indeed unfortunate that you can't have with's that apply only to
> the private part.  IMHO, the language would be better if the with's
> appeared *inside* the package, either at the start of the visible part,
> or the start of the private part, or the start of the body.  But I want
> them together, up front (for each of these parts) -- not scattered all
> over.

To enforce this we would need to formally define "start-of-a-part" in RM.
IMO it is easier to allow it everwhere with a stylistic note that it is
better to place it as early as possible in the text.

> By the way, I think there's an AI allowing with's to apply to the
> private part.  Something like "with private X" or "private with X".
> It still has to go outside, *before* the text of the package spec,
> which is unfortunate.  My suggestion of putting the with's inside is way
> too big a change to consider seriously.

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

Re: Other Ada Standards (was Re: SIGada Conference)

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: Or with getting rid of with clauses at all, as Robert Duff mentioned in
: passing! I never liked them. How about that?

That is what has been driving me up the wall when debugging
Java classes. The author liked a particular feature of the
IDE that popped up a menu of methods applicable to an object
if either the import list names the package, or if the fully
qualified named was there,
(type top.mid.Something.<hit Ctl-<space>>.)
Result: occurences of top.mid.Somthing.meth(...) everywhere
and _not_ top.mid.Something in the import list.

So, by just looking at the import list, nothing was known
about the dependences, because they were sprinkeled all over the
sources, and therfore implicit.
Can a good IDE help in this case? Not much I guess. To what extent can
it help when the source code cannot be compiled? I imagine that an
IDE might need error correction at an extreme AI guessing level so to
speak, in order to be helpful.

Should a programming language depend on an IDE?
There have been some extensions to Oberon-2, one being related to
concurrency, http://bluebottle.ethz.ch/languagereport/node3.html
AFAICS, if a maintainer wants to find the "concurrency structure"
of a an Active Oberon program, he/she will have to make a search
for some keywords embedded in type definitions, and prodecure
definitions.  (That is, it looks more like

    type T is
      program text
      program text
      protected
      program text
    end T;

rather than

    protected type T is
      program text
      program text
      program text
    end T;

The first variant might look quite flexible as you only have to add
some keyword like {ACTIVE} or {EXCLUSIVE} (for protected etc) after
some BEGIN.  To a reader this might look like you can add concurrency
ad hoc.  Or you might just switch some cuncurrency feature off for
a procedure by removing a keyword.  But then this is ad hoc design,
not easy to spot, and somehow feels not well structured, as it
buries the concurrency indicators in type definitions or procedure
implementations.  It might allow some clever tricks syntaxwise.
But do you want this kind of cleverness attitude expressed in
Ada programs?

Omitting with clauses might to have similar effects on design, I think.


-- Georg

Re: Other Ada Standards (was Re: SIGada Conference)

[Robert I. Eachus]

Dmitry A. Kazakov wrote:

> With/use issue is rather a cosmetic one. It might be very important for
> language promoting, though for those who are using Ada on daily basis, it
> is uninteresting, yet. Another very important cosmetic thing, (Robert
> Eachus and me mentioned it before) could be an ability to bundle a set of
> with's and use's in one package with then could be with-ed / used-ed
> instead.

Not me!  Unless I mentioned that I often do just that, but in a 
different way.  If I am composing several ADTs to create a type I 
certainly will do:

with A; with B; with C;
package Multiple is

    type ADT is ...

    package New_A is new A(ADT);
    package New_B is new B(ADT);
    package New_C is new C(ADT);

    function ... renames New_A...
    procedure ... renames New_B...
    ...

end Multiple;

Now for types that use the ADT, I only have to say:

with Multiple;

of course I will often follow it with:

use type Multiple.ADT;

to make the interesting subset of the declarations in ADT visible.  (If 
I need one of the uncommon operations from one of the instances, I will 
either use dotted notation or a use clause in some nested scope.)

> And these cosmetic things are about
> 
> - information hiding,
> - refactoring,
> - reuse
> 
> of declarations. Isn't it more than just an issue of training a text editor?

Yes, it is.  But what does it mean if you have a large set of unrelated 
packages withed by a large number of different units?  Bad design.  So 
adding something to the language to make it easier for bad designers to 
implement their designs, and harder on the readers than the bad design 
would otherwise be is not something we want to do.

Now look at what I did above, and think about interfaces.  Interfaces 
will make it easier to aggregate related units and when interfaces are 
used to implement the above pattern, and will make it even easier on the 
reader.  Unless there is a with for one of the instances used to 
implement an instance of an interface, the reader only needs to 
understand the interface to understand a unit where an interface 
instance is withed.

This is what I meant when I said that I think that adding interfaces to 
Ada will be a big benefit without considering multiple inheritance. 
Interfaces make it easier for a writer to communicate his intentions to 
readers.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Other Ada Standards (was Re: SIGada Conference)

[Robert A Duff]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> : Or with getting rid of with clauses at all, as Robert Duff mentioned in
> : passing! I never liked them. How about that?

For the record, I was not *advocating* the idea of getting rid of
with_clauses.  I *like* with_clauses, because they tell you, right up
front, what imports what.

I have some minor nitpicks.  I don't like using "with" as a verb (I
would have chosen "use" or "import" for this purpose).  It's annoying
that you can't apply a with_clause to a private part.  And the trivial
issue this thread has been endlessly discussing -- it seems silly to me
to say "with X; use X;", when "use X;" would suffice.

But no, I never meant to imply that it would be a good idea to get rid
of with_clauses!  I just meant that *if* you allow with_clauses to be
scattered all over (a bad idea, IMHO), you might as well get rid of them
(an equally bad idea, IMHO).

> That is what has been driving me up the wall when debugging
> Java classes.

Exactly!  I said "some other languages" don't have something like
with_clauses, but let you just refer to external stuff willy-nilly.
I had Java in mind when I wrote that.  I very much agree with Georg
Bauhaus that that's a flaw in Java, and I disagree with Dmitry
A. Kazakov that Ada should mimic that flaw.

Of course, I hope we all realize that no such changes can ever be made
to Ada, for compatibility and cost reasons.  So we're really talking
about "what if?" here, as an interesting exercise (not a realistic
change proposal for Ada).  What if we were designing a language from
scratch, with similar goals to Ada?  Would we eliminate with_clauses, or
allow them to be scattered all over?  I say, no.

- Bob

Re: Other Ada Standards (was Re: SIGada Conference)

[Dmitry A. Kazakov]

Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> : Or with getting rid of with clauses at all, as Robert Duff mentioned in
> : passing! I never liked them. How about that?
> 
> That is what has been driving me up the wall when debugging
> Java classes. The author liked a particular feature of the
> IDE that popped up a menu of methods applicable to an object
> if either the import list names the package, or if the fully
> qualified named was there,
> (type top.mid.Something.<hit Ctl-<space>>.)
> Result: occurences of top.mid.Somthing.meth(...) everywhere
> and _not_ top.mid.Something in the import list.
> 
> So, by just looking at the import list, nothing was known
> about the dependences, because they were sprinkeled all over the
> sources, and therfore implicit.

You are arguing against use-haters. I am not one. I am a with-hater! (:-))

> Can a good IDE help in this case? Not much I guess. To what extent can
> it help when the source code cannot be compiled? I imagine that an
> IDE might need error correction at an extreme AI guessing level so to
> speak, in order to be helpful.

True, the IDE argument is ultimately wrong. Wich also means that - why
should I worry about with A.B.C.D; use A.B.C.D;, I have a good editor! - is
also wrong. One can automate only typing, not reading.

> Should a programming language depend on an IDE?

Never

> There have been some extensions to Oberon-2, one being related to
> concurrency, http://bluebottle.ethz.ch/languagereport/node3.html
> AFAICS, if a maintainer wants to find the "concurrency structure"
> of a an Active Oberon program, he/she will have to make a search
> for some keywords embedded in type definitions, and prodecure
> definitions.  (That is, it looks more like
> 
>     type T is
>       program text
>       program text
>       protected
>       program text
>     end T;
> 
> rather than
> 
>     protected type T is
>       program text
>       program text
>       program text
>     end T;
> 
> The first variant might look quite flexible as you only have to add
> some keyword like {ACTIVE} or {EXCLUSIVE} (for protected etc) after
> some BEGIN.  To a reader this might look like you can add concurrency
> ad hoc.  Or you might just switch some cuncurrency feature off for
> a procedure by removing a keyword.  But then this is ad hoc design,
> not easy to spot, and somehow feels not well structured, as it
> buries the concurrency indicators in type definitions or procedure
> implementations.  It might allow some clever tricks syntaxwise.
> But do you want this kind of cleverness attitude expressed in
> Ada programs?

It is a difficult question, active objects, I mean. I would definitely like
task types being like any others, and to have multiple inheritance too.
Provided that, one could easily mix-in "activeness" to a type, for good and
for bad.

> Omitting with clauses might to have similar effects on design, I think.

I find "with"-ing boring. I cannot remember any case they helped me to solve
any problem. Rather, the opposite, it is sometimes difficult to with
everything you need. Moreover careless designers tend to "with" everything
they can. I am suspicious, whether others are doing it too, but just
removing extra with's afterwards! (:-))

The only use of "with" I found, was debugging. Without a good debugger I
added "with Text_IO;", and used Text_IO.Put_Line. When ready, I removed
"with Text_IO;", and could find all appearances of debug printing by
compiler error messages.

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

Re: Other Ada Standards (was Re: SIGada Conference)

[Dmitry A. Kazakov]

Robert I. Eachus wrote:

> Dmitry A. Kazakov wrote:
> 
>> With/use issue is rather a cosmetic one. It might be very important for
>> language promoting, though for those who are using Ada on daily basis, it
>> is uninteresting, yet. Another very important cosmetic thing, (Robert
>> Eachus and me mentioned it before) could be an ability to bundle a set of
>> with's and use's in one package with then could be with-ed / used-ed
>> instead.
> 
> Not me!  Unless I mentioned that I often do just that, but in a
> different way.  If I am composing several ADTs to create a type I
> certainly will do:
> 
> with A; with B; with C;
> package Multiple is
> 
>     type ADT is ...
> 
>     package New_A is new A(ADT);
>     package New_B is new B(ADT);
>     package New_C is new C(ADT);
> 
>     function ... renames New_A...
>     procedure ... renames New_B...
>     ...
> 
> end Multiple;
> 
> Now for types that use the ADT, I only have to say:
> 
> with Multiple;
> 
> of course I will often follow it with:
> 
> use type Multiple.ADT;
> 
> to make the interesting subset of the declarations in ADT visible.  (If
> I need one of the uncommon operations from one of the instances, I will
> either use dotted notation or a use clause in some nested scope.)
> 
>> And these cosmetic things are about
>> 
>> - information hiding,
>> - refactoring,
>> - reuse
>> 
>> of declarations. Isn't it more than just an issue of training a text
>> editor?
> 
> Yes, it is.  But what does it mean if you have a large set of unrelated
> packages withed by a large number of different units?  Bad design.

Right. But if they are related? Deeply nested generic child units? Does not
the language encorage designers to use larger compilation units because
otherwise users will be "punished" by larger with/use blocks?

> So
> adding something to the language to make it easier for bad designers to
> implement their designs, and harder on the readers than the bad design
> would otherwise be is not something we want to do.

I think that we have reached the level of complexity where it becomes a
heavy burden for a reader to analyze all with's and use's. Tools might
help, but there is still a problem.

> Now look at what I did above, and think about interfaces.  Interfaces
> will make it easier to aggregate related units and when interfaces are
> used to implement the above pattern, and will make it even easier on the
> reader.  Unless there is a with for one of the instances used to
> implement an instance of an interface, the reader only needs to
> understand the interface to understand a unit where an interface
> instance is withed.

True, this the same problem, but it is one level beneath. You are talking
about type interfaces, with/use issue is sort of "package interfaces". With
type interfaces and abstract types we can hide uninteresting details.
Probably it is time to go this way for packages.

> This is what I meant when I said that I think that adding interfaces to
> Ada will be a big benefit without considering multiple inheritance.
> Interfaces make it easier for a writer to communicate his intentions to
> readers.

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

Re: Other Ada Standards (was Re: SIGada Conference)

[Robert A Duff]

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

> Robert A Duff wrote:
> 
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> > 
> >> Just allow "with" everywhere "use" is allowed. Then "use A.B" could
> >> literally imply "with A.B".
> > 
> > That would defeat the whole purpose of with_clauses.  The point of
> > with's is that you can see a summary of the interconnections between
> > compilation units all in one spot, right up front.
> 
> Should a reader see these interconnections? Couldn't we bring the famous "it
> is a question of a good IDE" argument here?

Well, I suppose the IDE argument can always be used.  I'm a language
designer at heart, so I like like to provide readability via language
design.  I.e., I have a hammer, so I want to use my hammer.  ;-)

Maybe we should write programs in assembly language, and have a fancy
IDE that can figure out the design from the code, and make it all
readable and wonderful?  Seems like a bad approach to me.

I like the idea of an IDE (or just good-old Emacs) providing
*writeability*.  But usually, *readability* should be made easier by
language design, not by postulating fancy IDE's.

On the other hand, I have nothing against an IDE that can, say, produce
a graphical picture of the interdependencies among packages.

But on the other other hand, I want what I see on the screen (or paper)
to be readable.  I don't want to click on stuff to see what's going on
-- just looking at what's in front of me is far more efficient.

> > The most important aspects of a software design are: what are the
> > pieces, and which pieces interact with which other pieces.  Scattering
> > this information all over the place is a bad idea, IMHO.
> 
> Again, true. But it is not compilation units which interacts, but rather 
> smaller objects.

With clauses give the "big picture".  I don't want to click on some IDE
thingy that tells me this thing depends on everything else under the
Sun.  I want to see the overall design, more or less.

> > Why bother with with at all?  You might as well just say that any
> > reference to a name automatically imports that name, as necessary.
> > There are other languages that do something like that.
> 
> Absolutely. I think that the compilers are enough mature to go without with.
> Can we go so far? [with-ing generic children is really boring] Will
> implying of "with" be backward compatible?

I doubt if it could be made to work in the context of Ada, but other
languages have done it (Java, for example).  But I don't care to think
about that -- I was *not* seriously suggesting that eliminating
with_clauses is a good idea!

> >> So:
> >> 
> >> package A is
> >>    package B is
> >>    ...
> >> end A;
> >> 
> >> with A.B; -- This is OK, implies with A, as usual
> >> package C is
> >>    with A.B; -- This is also OK
> >> 
> >> BTW, this would give numerous addititional possibilities:
> >> 
> >> package X is
> >>    -- public things
> >> 
> >> private
> >>    with Something_Implementational.Not_To_Expose;
> > 
> > It is indeed unfortunate that you can't have with's that apply only to
> > the private part.  IMHO, the language would be better if the with's
> > appeared *inside* the package, either at the start of the visible part,
> > or the start of the private part, or the start of the body.  But I want
> > them together, up front (for each of these parts) -- not scattered all
> > over.
> 
> To enforce this we would need to formally define "start-of-a-part" in RM.

Not too hard.  For example, if the syntax were designed from scratch, it
would not be hard to have an "import clause" that can only appear at the
appropriate place.  Even without that, it's not too hard -- we already
require that "pragma Pure" appear "at the beginning", and there's some
verbiage in the RM to define what that means.

> IMO it is easier to allow it everwhere with a stylistic note that it is
> better to place it as early as possible in the text.

The problem with that is that you and I might have different ideas as to
where it's appropriate to put with_clauses.  So if I'm reading your
code, I have to search all over, because I can never be sure you
interpret the "stylistic note" the same way I do.  Better to define it
formally, and require the compiler to check it, so you and I can
understand each other's code.

- Bob

Re: Other Ada Standards (was Re: SIGada Conference)

[Dmitry A. Kazakov]

Robert A Duff wrote:

> Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
> 
>> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> : Or with getting rid of with clauses at all, as Robert Duff mentioned in
>> : passing! I never liked them. How about that?
> 
> For the record, I was not *advocating* the idea of getting rid of
> with_clauses.  I *like* with_clauses, because they tell you, right up
> front, what imports what.
> 
> I have some minor nitpicks.  I don't like using "with" as a verb (I
> would have chosen "use" or "import" for this purpose).  It's annoying
> that you can't apply a with_clause to a private part.

But this is pretty consistent with the idea of telling what will be imported
up front. Either you say, "with" is a global thing, so it has to be put
before anything else. Or you say, OK it is global, but let's pretend it is
not.

After all, semantically, one cannot "with" something in one part of a
compilation unit and not to do it in another. Or is it just about, whether
the compiler should allow the sequence of characters specified after "with"
as a name prefix?

> And the trivial
> issue this thread has been endlessly discussing -- it seems silly to me
> to say "with X; use X;", when "use X;" would suffice.

> But no, I never meant to imply that it would be a good idea to get rid
> of with_clauses!  I just meant that *if* you allow with_clauses to be
> scattered all over (a bad idea, IMHO), you might as well get rid of them
> (an equally bad idea, IMHO).

They are equivalent, but I am not so sure that they are bad.

>> That is what has been driving me up the wall when debugging
>> Java classes.
> 
> Exactly!  I said "some other languages" don't have something like
> with_clauses, but let you just refer to external stuff willy-nilly.
> I had Java in mind when I wrote that.  I very much agree with Georg
> Bauhaus that that's a flaw in Java, and I disagree with Dmitry
> A. Kazakov that Ada should mimic that flaw.
> 
> Of course, I hope we all realize that no such changes can ever be made
> to Ada, for compatibility and cost reasons. So we're really talking
> about "what if?" here, as an interesting exercise (not a realistic
> change proposal for Ada).

Yes, this all is hypothetically

> What if we were designing a language from
> scratch, with similar goals to Ada?  Would we eliminate with_clauses, or
> allow them to be scattered all over?  I say, no.

What is the idea behind "with"? A linker implemented on the basis of human
brains? A contract? If the latter then not only "private with", but also
presently allowed "with" in the bodies has to be outlawed. What is the use
of such a contract otherwise? It just makes no sense. And if it could, then
I would prefer "without" clause, to specify which units are *not*
referenced by a unit!

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

Re: Other Ada Standards (was Re: SIGada Conference)

[Russ]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:<bsmfaq$d8f2i$1@ID-77047.news.uni-berlin.de>...

> With/use issue is rather a cosmetic one. It might be very important for
> language promoting, though for those who are using Ada on daily basis, it
> is uninteresting, yet.

Yes, it's mainly a cosmetic issue, but it also has to do with not
forcing the *reader* to read the same thing twice and verify that it
is indeed the same thing. And yes, I can understand why it might be
uninteresting to people who use Ada regularly. They are wrestling with
much more complicated issues. But I also understand that most of the
folks here would like to see a wider acceptance of Ada. And the double
naming of library units is the first thing that a prospective new user
of Ada sees in Ada source code.

As anyone who has ever tried to sell anything knows, "cosmetics" and
first impressions are important. Ask any woman trying to attract a
mate. ;^)

Re: Other Ada Standards (was Re: SIGada Conference)

[Wes Groleau]

Russ wrote:
> folks here would like to see a wider acceptance of Ada. And the double
> naming of library units is the first thing that a prospective new user
> of Ada sees in Ada source code.

Since many (fortunately not all) have such a
pathological fear of 'use' I wouldn't expect
a new user to see a lot of 'with X; use X;'

-- 
Wes Groleau
   "To know what you prefer, instead of humbly saying
    Amen to what the world tells you you should prefer,
    is to have kept your soul alive."
                          -- Robert Louis Stevenson

Re: Other Ada Standards (was Re: SIGada Conference)

[Robert I. Eachus]

Dmitry A. Kazakov wrote:

> Right. But if they are related? Deeply nested generic child units? Does not
> the language encorage designers to use larger compilation units because
> otherwise users will be "punished" by larger with/use blocks?

This was an occasional problem in Ada 83, in Ada 95 I think the only 
major case left to fix is mutually interdependent types.  And it will be 
fixed.

But as a writer you have to ask yourself, every time you go to with 
something that wasn't in your original design, whether the design was 
wrong, or your implementation is wrong.  I guess I find three about 
equal sized groups of cases:  The original design WAS wrong, the 
implementation chosen is not wrong, but does need more visibility 
(almost always in the body) than was anticipated by the design, and the 
third case, this implementation is wrong, fix it.

If you take that attitude, the number of with clauses is just not a burden.

> I think that we have reached the level of complexity where it becomes a
> heavy burden for a reader to analyze all with's and use's. Tools might
> help, but there is still a problem.

No real argument with that statement, just a warning.  When a project 
does get to that point, you had better be almost finished, or go back 
now and do a redesign.  At MITRE we found that this was one of the 
nicest things about Ada.  When the contractor started complaining about 
slow compiles or needing better tools, it was time to examine the source 
and compare it to the design documents.  Almost always there was a 
particular design problem that needed to be fixed.  Sometimes it was 
"just" a programming problem, but often it reflected too ambitious (and 
unrealistic) requirements or serious hardware problems.

One of my favorite examples involved a lot of kludgeware to merge two 
message streams.  Why merge the message streams?  Well the requirements 
specified a throughput of more messages per minute than one 9600 baud 
connection could handle.  But the actual requirement anticipated that 
many messages over a single channel.  We allowed the contractor to test 
with a 19200 connection, and went back to the government customer to 
figure out if the requirement was real, and we should upgrade the 
communications hardware. (It turned out to be cheaper to upgrade the 
modems than redo the requirements analysis. ;-)

> True, this the same problem, but it is one level beneath. You are talking
> about type interfaces, with/use issue is sort of "package interfaces". With
> type interfaces and abstract types we can hide uninteresting details.
> Probably it is time to go this way for packages.

No, it is the same issue.  Interface inheritance will allow a package to 
import several ADTs and combine them in one new type.  But the package 
that contains the interface instantiation will EXPORT all of the 
operations that are collected by the interface.  So users of the type 
created by the interface instance will only need to with (and possibly 
use) one package, not several.

You can do, and I do, the same thing today with a succession of type 
derivations, each using a generic mix-in.  Interfaces will make this 
easier. The private part of a package containing a series of mix-ins can 
get pretty long, and you often need to do some renames in the package 
body.  If you want to call this multiple inheritance, fine.  But I think 
of it as constructing a type from component ADTs.  Whether there is an 
isa relationship to several types, or just a record type with several 
component ADTs, the program structure is the same:  The unit that 
creates the ADT has withs for the compontents, users of the created ADT 
need only with one unit.

If the average number of withs per package is say two per spec and three 
or four per body, you are doing good.  Four per spec and ten per body is 
acceptable in a final product.  But when it looks like you are getting 
beyond that watch out.  Doing the necessary refactoring will take time, 
but it will reduce the number of bugs to be found once coding is 
complete drastically.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Other Ada Standards (was Re: SIGada Conference)

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: I find "with"-ing boring. I cannot remember any case they helped me to solve
: any problem.

They might help others solving a problem :-)
with clauses might mark stars, followers, and independents in a network of
dependent units. Many with clauses -> unit is very likely a star.
If there are many stars, and no clique, something could be
wrong. In this sense with clauses document design and might indicate
problems. 

As an example, think of a class that takes on several roles but does
so only by way of a single huge collection of state variables cobbled
together.  (The (Java) class I am thinking of still exist; there is
some hope that it will be replaced .-)
That is, the states could have been grouped semantically
but have not been grouped using language means for grouping. Can
one build this class without a long list of with clauses somewhere
(or by writing a larger number of "provider" packages nested in the
same block so they can be seen where the type is declared,
or worse, a large package providing everything)?

Maybe it is easier to think about the correctness of what is happening
inside a package if the number of with clauses is low?

: Moreover careless designers tend to "with" everything
: they can.

So "with" is a useful indicator to maintainers?
 

-- Georg

Re: Other Ada Standards (was Re: SIGada Conference)

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: Moreover careless designers tend to "with" everything
: they can.

Run the Java 2 library through a reverse engineering tool
that produces a a graph of the static class structure :-)


-- Georg

Re: Other Ada Standards (was Re: SIGada Conference)

[Dmitry A. Kazakov]

Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> : I find "with"-ing boring. I cannot remember any case they helped me to
> : solve any problem.
> 
> They might help others solving a problem :-)
> with clauses might mark stars, followers, and independents in a network of
> dependent units. Many with clauses -> unit is very likely a star.
> If there are many stars, and no clique, something could be
> wrong. In this sense with clauses document design and might indicate
> problems.

I think that children packages do the job much better. They have a
substance, they extend/implement parents. As for "with", they lack any
substance. A program with a superfluos "with" remains valid, always. This
is an important sign. For example, "use" has a substance, because you can
break a program if you add a "use" causing a name conflict. BTW, if there
where a way to prevent name conflicts I would argue to get rid of "use".
Unfortunately there is no one.

> As an example, think of a class that takes on several roles but does
> so only by way of a single huge collection of state variables cobbled
> together.  (The (Java) class I am thinking of still exist; there is
> some hope that it will be replaced .-)
> That is, the states could have been grouped semantically
> but have not been grouped using language means for grouping. Can
> one build this class without a long list of with clauses somewhere
> (or by writing a larger number of "provider" packages nested in the
> same block so they can be seen where the type is declared,
> or worse, a large package providing everything)?

It is an interesting problem. There is a similar problem with ADT - "fat
classes". The base types tend to rapidly grow by adding more and more
primitive operations. It is very difficult to keep new pritive operations
in derived types, against the "gravity" force which attracts everything to
the base.

> Maybe it is easier to think about the correctness of what is happening
> inside a package if the number of with clauses is low?
> 
> : Moreover careless designers tend to "with" everything
> : they can.
> 
> So "with" is a useful indicator to maintainers?

Oh yes, but the number of source code lines is also an indicator. Should we
follow Basic by explicit numbering them? The point is that, yes, the
package dependencies is an important metric. But this by no means implies a
necessity to force a designer to *manually* measure it and then include it
in the code!

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

Re: Other Ada Standards (was Re: SIGada Conference)

[Dmitry A. Kazakov]

Robert I. Eachus wrote:

> Dmitry A. Kazakov wrote:
> 
>> Right. But if they are related? Deeply nested generic child units? Does
>> not the language encorage designers to use larger compilation units
>> because otherwise users will be "punished" by larger with/use blocks?
> 
> This was an occasional problem in Ada 83, in Ada 95 I think the only
> major case left to fix is mutually interdependent types.  And it will be
> fixed.
> 
> But as a writer you have to ask yourself, every time you go to with
> something that wasn't in your original design, whether the design was
> wrong, or your implementation is wrong.  I guess I find three about
> equal sized groups of cases:  The original design WAS wrong, the
> implementation chosen is not wrong, but does need more visibility
> (almost always in the body) than was anticipated by the design, and the
> third case, this implementation is wrong, fix it.
> 
> If you take that attitude, the number of with clauses is just not a
> burden.

It is not. As I said, it is a cosmetic issue, in most cases.

But it is definitely a burden for newcomers and for occasional users of
library packages. Imagine, one Ada becomes popular, this means that it will
have thousands of libraries. And alas, it will be used for poorly designed
write-once-run-once applications.

>> I think that we have reached the level of complexity where it becomes a
>> heavy burden for a reader to analyze all with's and use's. Tools might
>> help, but there is still a problem.
> 
> No real argument with that statement, just a warning.  When a project
> does get to that point, you had better be almost finished, or go back
> now and do a redesign.  At MITRE we found that this was one of the
> nicest things about Ada.  When the contractor started complaining about
> slow compiles or needing better tools, it was time to examine the source
> and compare it to the design documents.  Almost always there was a
> particular design problem that needed to be fixed.  Sometimes it was
> "just" a programming problem, but often it reflected too ambitious (and
> unrealistic) requirements or serious hardware problems.

Excellent point. Up to some level of complexity numerous with's definitely
indicate a problem, because we a-priory know that there should a way to do
it right, at *this* level.

> One of my favorite examples involved a lot of kludgeware to merge two
> message streams.  Why merge the message streams?  Well the requirements
> specified a throughput of more messages per minute than one 9600 baud
> connection could handle.  But the actual requirement anticipated that
> many messages over a single channel.  We allowed the contractor to test
> with a 19200 connection, and went back to the government customer to
> figure out if the requirement was real, and we should upgrade the
> communications hardware. (It turned out to be cheaper to upgrade the
> modems than redo the requirements analysis. ;-)

So, change the requirements, if you cannot fulfil them! (:-))

>> True, this the same problem, but it is one level beneath. You are talking
>> about type interfaces, with/use issue is sort of "package interfaces".
>> With type interfaces and abstract types we can hide uninteresting
>> details. Probably it is time to go this way for packages.
> 
> No, it is the same issue.  Interface inheritance will allow a package to
> import several ADTs and combine them in one new type.  But the package
> that contains the interface instantiation will EXPORT all of the
> operations that are collected by the interface.  So users of the type
> created by the interface instance will only need to with (and possibly
> use) one package, not several.

Yes, it would definitely help, but

1. It is still manual. I'd wish to have a method to automate this. I.e. to
create proxy types more easily.

2. Not everything is a type. One might wish to "stream" objects and packages
through another "interface" package.

> You can do, and I do, the same thing today with a succession of type
> derivations, each using a generic mix-in.  Interfaces will make this
> easier. The private part of a package containing a series of mix-ins can
> get pretty long, and you often need to do some renames in the package
> body.  If you want to call this multiple inheritance, fine.  But I think
> of it as constructing a type from component ADTs.  Whether there is an
> isa relationship to several types, or just a record type with several
> component ADTs, the program structure is the same:  The unit that
> creates the ADT has withs for the compontents, users of the created ADT
> need only with one unit.
> 
> If the average number of withs per package is say two per spec and three
> or four per body, you are doing good.  Four per spec and ten per body is
> acceptable in a final product.  But when it looks like you are getting
> beyond that watch out.  Doing the necessary refactoring will take time,
> but it will reduce the number of bugs to be found once coding is
> complete drastically.

This metric is good, but sometimes it can be misleading. If using an
external library it might indicate rather a problem in the library design.
Win32 or UNIX thin bindings are inevitably bad. Then the rule that with-ing
a child implies with-ing the parent causes aberrations in the metric:

with A.B.C.D; -- One with

with A;
with A_B;
with A_B_C;
with A_B_C_D; -- Four

Though semantically the second might be same. For example A_B could be an
instantiation of a generic child of A.

Then "use A.B;" does not imply "use A;", so the number of use's might
explode even if the design is not so afwully bad. The "use all A.B.C;"
proposal might help. But I'd like to have a finer control over what will be
with/use-d, i.e. "interface" packages. It could be a great help for big
libraries. One could make a set of "interface" packages providing different
views on the library, not necessarily reflecting the design of the library.

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

Re: Other Ada Standards (was Re: SIGada Conference)

[Chad R. Meiners]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:bsp2po$epgut$2@ID-77047.news.uni-berlin.de...
> Oh yes, but the number of source code lines is also an indicator. Should
we
> follow Basic by explicit numbering them? The point is that,

I just can't let this bad analogy lie ... ;-)
When BASIC required lines numbers it didn't enforce that the numbering had
anything to do with the actual number of lines.

10 PRINT "Hello World":
15 PRINT "."
20 STOP

Gee, this program doesn't look like it contains twenty lines ;-)

-CRM

Re: Other Ada Standards (was Re: SIGada Conference)

[Chad R. Meiners]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:bsp2pt$epgut$3@ID-77047.news.uni-berlin.de...
> So, change the requirements, if you cannot fulfil them! (:-))

Call me crazy, but I always thought that this was both the ethical and
practical thing to do.  ;-) I not saying that you should change them
silently, though.

-CRM

Re: Other Ada Standards (was Re: SIGada Conference)

[Robert I. Eachus]

Chad R. Meiners wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:bsp2pt$epgut$3@ID-77047.news.uni-berlin.de...
> 
>>So, change the requirements, if you cannot fulfil them! (:-))
> 
> 
> Call me crazy, but I always thought that this was both the ethical and
> practical thing to do.  ;-) I not saying that you should change them
> silently, though.

In the case I described, the cost of even reviewing the requirement 
would have been huge compared to buying two or three dozen 19200 modems 
instead of 9600 baud modems.  By the time the system was fielded, the 
19.2k modems cost less than the 9600 baud modems had been priced at. 
Even one teleconference meeting would have cost more, but in this case, 
due to the classified nature of the material which resulted in the 
requirements, it would have had to be a face-to-face meeting.  It 
probably could have been piggybacked on another meeting, but as I said, 
why bother, the actual cost to upgrade the hardware was under $2000.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Re: Other Ada Standards (was Re: SIGada Conference)

[Peter Richtmyer]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccwu8ije3d.fsf@shell01.TheWorld.com>...
> 
> That would defeat the whole purpose of with_clauses.  The point of
> with's is that you can see a summary of the interconnections between
> compilation units all in one spot, right up front.
> 

I wish this were true! Just look in one place.

However, take a not-too-unusual situation of a package spec and body 
with a few "separate" routines, and perhaps some child packages 
with a few separates each. "Good practice" says put the with's 
down where needed, not all in the pkg spec. So in a child pkg 
separate, you need to look in up to 5 different files to see 
what might be used (with'd) by the separate. For the entire package, 
you need to look at all the files to see what all the "interconnections"
are.

Or do you advocate putting them all in the spec?

(I remember an engineer took over a pgm of mine once. First thing she did 
was move all the with's into the package specs. Then she complained
to me that my program would not compile and she had to spend alot 
of time redesigning and recoding it.) (It was already working).

regards,
Peter

Re: Other Ada Standards (was Re: SIGada Conference)

[Alexandre E. Kopilovitch]

Peter Richtmyer wrote:

> >  The point of
> > with's is that you can see a summary of the interconnections between
> > compilation units all in one spot, right up front.
> > 
>
> I wish this were true! Just look in one place.
>
> However, take a not-too-unusual situation of a package spec and body 
> with a few "separate" routines, and perhaps some child packages 
> with a few separates each. "Good practice" says put the with's 
> down where needed, not all in the pkg spec. So in a child pkg 
> separate, you need to look in up to 5 different files to see 
> what might be used (with'd) by the separate. For the entire package, 
> you need to look at all the files to see what all the "interconnections"
> are.
>
> Or do you advocate putting them all in the spec?

Perhaps this is a case when an opportunity to centralize the whole context
explicitly - using the construct I mentioned in this newsgroup about a week
ago:

  package XXX context is
    with ...;
    ...
  end XXX;

  package body XXX context is
    with ...;
  end XXX;

would be useful. The most interesting value of (optional) separation of the
whole context (or, perhaps, part of it) is in that it eases various extentions
and ramifications of the notion of context. For example, "with" for private
part can be easily introduced, and specific contexts for separate routines
also may be incorporated in this condtruct without much difficulty.



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

Re: Other Ada Standards (was Re: SIGada Conference)

[Pascal Obry]

Robert A Duff <bobduff@shell01.TheWorld.com> writes:

> > Personally, I'd rather have to type two lines of code (over and over
> > again, if necessary) than to develop my own matrix math, stats package,
> > operations research math, etc.
> 
> The issue has nothing to do with how much you have to type.  

Well it is not mandatory to put the with and use clauses for the same package
on the same line. See AWS sources for example. The with are before the unit
and the use are put if possible in the deepest nested block, sometimes for the
whole package. So the editor won't help here ;)

The "with and use" proposal will just "help" people to ALWAYS use packages.
I think this is wrong. You bet it, I do not like use clause and use them only
for packages design to be "used" (like Ada.Strings.Unbounded for example) or
empty root packages like Ada or GNAT.

Just my 2 cents, and Happy New Year!

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

[Jean-Pierre Rosen]

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


"Hyman Rosen" <hyrosen@mail.com> a �crit dans le message de news:1071687303.254780@master.nyc.kbcfp.com...
> Jean-Pierre Rosen wrote:
> > "Hyman Rosen" <hyrosen@mail.com> a �crit
> >>I expect this is just the usual "simulate MI with access discriminants"
> >>bit that always comes up here. I think it can do everything except support
> >>cross-casting.
> >
> > It can. See my paper at http://www.adalog.fr/publicat/ada-interfaces.pdf
>
> Does this mean that you think it can support cross-casting,
> or do you agree that it cannot? That is, in Java, I may have
> two interfaces:
>      interface IF_1 { }    interface IF_2 { }
> and given an object of type IF_1, I may try to see if it is
> also of type IF_2:
>      boolean is_both(IF_1 o) { return o instanceof IF_2; }
> and if it is, I can cross-cast:
>      IF_2 as_IF_2(IF_1 o) { return is_both(o) ? (IF_2)o : null; }
>
> Note that I can do this without any knowledge at all of the
> existence of one or more parent types which implement both
> interfaces. I don't think this can be done with the inner class/
> access discriminant approach.
>
What I meant is that if class A implements interface IF, and you get an object as an IF, you can get a view of it as an A. I didn't
consider the case you mention - presumably because I never met a need for it!

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

Re: SIGada Conference

[Hyman Rosen]

Jean-Pierre Rosen wrote:
 > presumably because I never met a need for it!

I think it has its place in some low-level framework
code, as a means of querying whether an object supports
a particular interface. In any case, it's an ability
that exists with MI or interfaces, and you need to know
about it when thinking about ways to emulate those
features without fully supporting them. Typically, this
kind of interface querying involves a runtime search in
the type information structure or virtual table of the
object being examined, and that's not available in the
homebrew version.