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

["Robert I. Eachus" <rieachus@comcast.net>]

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