Let's change semantics of "use type"

Let's change semantics of "use type"

[Victor Porton]

I am suggesting (for the next Standard) to change the semantics of "use
type" so that it would make visible not only primitive _operators_, but
all primitive _operations_.

It seems (at the first glance) that changing Standard such the way would
not make any correct program incorrect. (However it would make some current
programs not compilable. If this is too bad, it can be instead denoted as
"use all type;" for using all operations, not only operators.)

The rationale is that this is a convenient way for dealing with a type 
imported from a package without the need of many rename directives.  These
directives may make a long list and are "dirty" for both writing and
reading. (Reading this list one may not understand for exactly what is
present an item of the list and so not know (without experiment with a
compiler) whether this item can be removed without breaking the program.
So in certain sense the current Ada is not perfectly readable.) With "use
all type" programmers will less tend to write multi-level designators
which are both unreadable (especially when there are several such
designators in an expression) and error-prone as one may forget y in
x.y.z (mistakedly writing x.z) and get wrong behavior of the program.

Re: Let's change semantics of "use type"

[Adrian Hoe]

Victor Porton wrote:

> I am suggesting (for the next Standard) to change the semantics of "use
> type" so that it would make visible not only primitive _operators_, but
> all primitive _operations_.
> 
> It seems (at the first glance) that changing Standard such the way would
> not make any correct program incorrect. (However it would make some current
> programs not compilable. If this is too bad, it can be instead denoted as
> "use all type;" for using all operations, not only operators.)
> 
> The rationale is that this is a convenient way for dealing with a type 
> imported from a package without the need of many rename directives.  These
> directives may make a long list and are "dirty" for both writing and
> reading. (Reading this list one may not understand for exactly what is
> present an item of the list and so not know (without experiment with a
> compiler) whether this item can be removed without breaking the program.
> So in certain sense the current Ada is not perfectly readable.) With "use
> all type" programmers will less tend to write multi-level designators
> which are both unreadable (especially when there are several such
> designators in an expression) and error-prone as one may forget y in
> x.y.z (mistakedly writing x.z) and get wrong behavior of the program.
> 


Without the rename directives, the program will be difficult to 
understand. With your suggestion of "use all type" may be good for 
short programs but not "large" program.

I would prefer current standards for a typical large with hundreds 
thousand lines of code (if not million) will be easily understood.
-- 
type Dmitry is new Adrian;           -- Adrian Hoe
                                      -- http://adrianhoe.com
                                      -- Remove *nospam* to email

Re: Let's change semantics of "use type"

[Robert A Duff]

porton@ex-code.com (Victor Porton) writes:

> I am suggesting (for the next Standard) to change the semantics of "use
> type" so that it would make visible not only primitive _operators_, but
> all primitive _operations_.

Why not just "use" the package in which the type is declared?
Why is this worth modifying the language?

> It seems (at the first glance) that changing Standard such the way would
> not make any correct program incorrect.

I think you mean, "...would not change the run-time semantics".
If so, I agree.

>... (However it would make some current
> programs not compilable. If this is too bad, it can be instead denoted as
> "use all type;" for using all operations, not only operators.)
> 
> The rationale is that this is a convenient way for dealing with a type 
> imported from a package without the need of many rename directives.  These
> directives may make a long list and are "dirty" for both writing and
> reading. (Reading this list one may not understand for exactly what is
> present an item of the list and so not know (without experiment with a
> compiler) whether this item can be removed without breaking the program.
> So in certain sense the current Ada is not perfectly readable.) With "use
> all type" programmers will less tend to write multi-level designators
> which are both unreadable (especially when there are several such
> designators in an expression) and error-prone as one may forget y in
> x.y.z (mistakedly writing x.z) and get wrong behavior of the program.

Agreed: long boring sequences of code are evil.

- Bob

Re: Let's change semantics of "use type"

[Randy Brukardt]

Robert A Duff wrote in message ...
>porton@ex-code.com (Victor Porton) writes:
>
>> I am suggesting (for the next Standard) to change the semantics of
"use
>> type" so that it would make visible not only primitive _operators_,
but
>> all primitive _operations_.
>
>Why not just "use" the package in which the type is declared?
>Why is this worth modifying the language?


There are some subtle differences in semantics (especially that you
don't need know the name of the package for a "use type"), but in
general, "use" is essentially the same as "use type all".

In general, I don't see the point. It seems that this is primarily a way
to get around a "no use" coding standard. However, such a standard would
almost certainly be revised to include "no use type all", so it wouldn't
help anything.

As far as avoiding long lists of renames, that's easy. Don't write them!
There's no point. Either use "use" when it is appropriate, use the full
dot notation, or (if the package names are too long to handle) rename
the package. (And for the latter, I'd suggest choosing better package
names is preferable.)

The vast majority of my code avoids use clauses. I don't have a problem
reading (or writing)
       Claw.Edit.Multiline.Create (...);
instead of
       Create (...);

              Randy.

Re: Let's change semantics of "use type"

[Victor Porton]

In article <wcc65v8i3lh.fsf@shell01.theworld.com>,
	Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> porton@ex-code.com (Victor Porton) writes:
> 
>> I am suggesting (for the next Standard) to change the semantics of "use
>> type" so that it would make visible not only primitive _operators_, but
>> all primitive _operations_.
> 
> Why not just "use" the package in which the type is declared?
> Why is this worth modifying the language?

There are many writings on why "use" package is an evil:
It may expose something unintentionally especially when
switching to a new version of a package. This unintentionally
used identifier may cause program behavior different from
intended by a not enough careful programmer (everybody).

I retell that I also suggested an alternate syntax "use all type".

Re: Let's change semantics of "use type"

[Robert A Duff]

porton@ex-code.com (Victor Porton) writes:

> In article <wcc65v8i3lh.fsf@shell01.theworld.com>,
> 	Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> > porton@ex-code.com (Victor Porton) writes:
> > 
> >> I am suggesting (for the next Standard) to change the semantics of "use
> >> type" so that it would make visible not only primitive _operators_, but
> >> all primitive _operations_.
> > 
> > Why not just "use" the package in which the type is declared?
> > Why is this worth modifying the language?
> 
> There are many writings on why "use" package is an evil:
> It may expose something unintentionally especially when
> switching to a new version of a package. This unintentionally
> used identifier may cause program behavior different from
> intended by a not enough careful programmer (everybody).
> 
> I retell that I also suggested an alternate syntax "use all type".

My point was that changing the syntax from "use P;" to "use all P.T;"
won't eliminate the supposed "dangers" of use clauses.  Most packages
contain a type, plus operations on the type, so the two syntaxes mean
*almost* the same thing, in practice.

- Bob

Re: Let's change semantics of "use type"

[Victor Porton]

In article <wccwunmg477.fsf@shell01.theworld.com>,
	Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> porton@ex-code.com (Victor Porton) writes:
> 
>> In article <wcc65v8i3lh.fsf@shell01.theworld.com>,
>> 	Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>> > porton@ex-code.com (Victor Porton) writes:
>> > 
>> >> I am suggesting (for the next Standard) to change the semantics of "use
>> >> type" so that it would make visible not only primitive _operators_, but
>> >> all primitive _operations_.
> 
> My point was that changing the syntax from "use P;" to "use all P.T;"
> won't eliminate the supposed "dangers" of use clauses.  Most packages
> contain a type, plus operations on the type, so the two syntaxes mean
> *almost* the same thing, in practice.

"use all type" is namely against such the packages which contain 
something other among operations on a type and also against such
packages which define several types.

Consider also packages which define operations on class wide types.
"use"ing such a package may be dangerous as it may bring operations
on a not supposed concrete types.

Well, which dangers "use all type" has? Personally I when deal with
a type almost always want all its primitive operations. Getting all
primitive operations of a type seems nearly safe.

Also both standartizing and implementing "use all type" would be
*very* simple. Why not?

Re: Let's change semantics of "use type"

[Robert A Duff]

porton@ex-code.com (Victor Porton) writes:

> "use all type" is namely against such the packages which contain 
> something other among operations on a type and also against such
> packages which define several types.
> 
> Consider also packages which define operations on class wide types.
> "use"ing such a package may be dangerous as it may bring operations
> on a not supposed concrete types.

I don't understand the problem.

> Well, which dangers "use all type" has? Personally I when deal with
> a type almost always want all its primitive operations. Getting all
> primitive operations of a type seems nearly safe.

But when you deal with a type you also want various class-wide
operations, and exceptions that are raised by primitive operations of
the type, and generic units that are related to the type, and constants
of the type.  In particular, you want everything related to the type.
In other words, you want everything declared in the same package as the
type.  Or, you want to use dot-selection notation.  These possibilities
already exist.

> Also both standartizing and implementing "use all type" would be
> *very* simple. Why not?

There is no particular "danger" to "use all type".  It's just not useful
enough to consider adding to the language.  All language changes, even
fairly simple ones, have some cost: compilers must change, the RM needs
wording, programmers have more features to learn about.

- Bob

Re: Let's change semantics of "use type"

[Ted Dennison]

porton@ex-code.com (Victor Porton) wrote in message news:<3dcb8347$0$299$bed64819@news.gradwell.net>...
> I am suggesting (for the next Standard) to change the semantics of "use
> type" so that it would make visible not only primitive _operators_, but
> all primitive _operations_.

Ick.

> The rationale is that this is a convenient way for dealing with a type 
> imported from a package without the need of many rename directives.  These

I've done quite a bit of tagged type programming in Ada95, and I have
*never* used a rename that way. In fact, I don't believe I've used a
single rename in Ada95 ever...

> So in certain sense the current Ada is not perfectly readable.) With "use
> all type" programmers will less tend to write multi-level designators
> which are both unreadable (especially when there are several such

Its "unreadable" only if things are misnamed. A decent Ada developer
should realize how his services are going to look when the clients try
to use them in code, and name them accordingly.

> designators in an expression) and error-prone as one may forget y in
> x.y.z (mistakedly writing x.z) and get wrong behavior of the program.

I'm not exactly sure how that could happen. Routines can't be
"primitive" and exist in different packages. So the situation you
envision would not make it past the compiler.

Additionally, anyone who makes a package that is named after an
"uncle" package needs to be worked over with a cluestick until
enlightenment is achieved.

Re: Let's change semantics of "use type"

[R. Tim Coslet]

The only real use I have ever found in Ada95 for rename is when I need to
make repeated references to the same array element in several places in a
block of code. I rename the array element (to tell the compiler to index it
only once) then use the new name in the places in the code that reference
it.

Example:

    declare
        Selected_Item : Some_Typ renames Big_Arrayo_of_Data(x,y,z);
    begin
        if Selected_Item = Special_Value then
            y := Complex_Function(Selected_Item,z);
            ... more code refering to Selected_Item ...
        end if;
        Selected_Item := Fancy_Function(x,i);
    end;

Note: in the above code the change in y does NOT affect the item already
indexed, so Selected_Item still refers to the same item.

-- 
        R. Tim Coslet
        r_tim_coslet@pacbell.net

Technology, n. Domesticated natural phenomena.


> From: dennison@telepath.com (Ted Dennison)
> Organization: http://groups.google.com/
> Newsgroups: comp.lang.ada
> Date: 11 Nov 2002 07:59:47 -0800
> Subject: Re: Let's change semantics of "use type"
> 
> 
> I've done quite a bit of tagged type programming in Ada95, and I have
> *never* used a rename that way. In fact, I don't believe I've used a
> single rename in Ada95 ever...
> 

Re: Let's change semantics of "use type"

[Ted Dennison]

"R. Tim Coslet" <R_Tim_Coslet@pacbell.net> wrote in message news:<B9F5F98B.5DE7%R_Tim_Coslet@pacbell.net>...
> The only real use I have ever found in Ada95 for rename is when I need to
> make repeated references to the same array element in several places in a
> block of code. I rename the array element (to tell the compiler to index it
> only once) then use the new name in the places in the code that reference
> it.
> 
> Example:
> 
>     declare
>         Selected_Item : Some_Typ renames Big_Arrayo_of_Data(x,y,z);
>     begin
>         if Selected_Item = Special_Value then
>             y := Complex_Function(Selected_Item,z);
>             ... more code refering to Selected_Item ...
>         end if;
>         Selected_Item := Fancy_Function(x,i);
>     end;

Were it me, I'd replace this entire declare block with a routine. In
fact, were I to come across this in code I was reading, I'd certianly
refactor it as such. The interfaces into and out of a routine are much
narrower and better defined, so they are far better from a maintanence
(and code understanding) standpoint.

In fact, its quite rare that I *ever* use a declare block for anything
other than localizing exception handling.

Re: Let's change semantics of "use type"

[Preben Randhol]

Ted Dennison wrote:
> In fact, its quite rare that I *ever* use a declare block for anything
> other than localizing exception handling.

I use it to handle strings as well. Then I don't have to use (un)bounded.

-- 
Preben Randhol ------------------------ http://www.pvv.org/~randhol/ --
�There are three things you can do to a woman. You can love her, suffer
 for her, or turn her into literature.�  - Justine, by Lawrence Durrell

Re: Let's change semantics of "use type"

[Victor Porton]

In article <wccof8wuo5u.fsf@shell01.theworld.com>,
	Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> porton@ex-code.com (Victor Porton) writes:
> 
>> "use all type" is namely against such the packages which contain 
>> something other among operations on a type and also against such
>> packages which define several types.
>> 
>> Consider also packages which define operations on class wide types.
>> "use"ing such a package may be dangerous as it may bring operations
>> on a not supposed concrete types.
> 
> I don't understand the problem.

package P is
  type A_Type is ...;
  
  procedure A(X: A_Type);
  
  procedure B(I: Integer);
end P;

"use"ing P would bring B which is likely to conflict or to "tempt".
(In real life B may be some procedure for incrementing erference
counter or like.)

>> Well, which dangers "use all type" has? Personally I when deal with
>> a type almost always want all its primitive operations. Getting all
>> primitive operations of a type seems nearly safe.
> 
> But when you deal with a type you also want various class-wide
> operations, and exceptions that are raised by primitive operations of
> the type, and generic units that are related to the type, and constants
> of the type.  In particular, you want everything related to the type.
> In other words, you want everything declared in the same package as the
> type.  Or, you want to use dot-selection notation.  These possibilities
> already exist.

Yes, I forgot about class wide operations; they also should be
brought to visibility by "use all type". Exceptions are commonly
not multiduous, so using a prefix notation or a rename isn't a
great problem with exceptions. Aproximately the same for constants.
Generic units are not overloadable, so these should also be not
brought to visibility, sorry for this.

"use all type" much shortens the list which we need to do manually
(without dangerous "use" directive).

Re: Let's change semantics of "use type"

[Victor Porton]

In article <4519e058.0211110759.3ebbf128@posting.google.com>,
	dennison@telepath.com (Ted Dennison) writes:
> porton@ex-code.com (Victor Porton) wrote in message news:<3dcb8347$0$299$bed64819@news.gradwell.net>...
>
>> designators in an expression) and error-prone as one may forget y in
>> x.y.z (mistakedly writing x.z) and get wrong behavior of the program.
> 
> I'm not exactly sure how that could happen. Routines can't be
> "primitive" and exist in different packages. So the situation you
> envision would not make it past the compiler.

I am not about primitive operations here, but just about
any multi-level designators.

Re: Let's change semantics of "use type"

[Richard Riehle]

Victor Porton wrote:

> I am suggesting (for the next Standard) to change the semantics of "use
> type" so that it would make visible not only primitive _operators_, but
> all primitive _operations_.
>

Snipped the explanatory text.

We should be cautious about adding features to the Ada
language that will dilute its essential power.   We should
be wary of trying to make Ada look like something else
in pursuit of a potentially ephemeral popularity.  Ada is
what it is:  a language designed to enable the compiler to
detect the maximum number of errors as early in the
development process as possible and to continue catching
errors during execution and over the full life-cycle of the
maintenance process.

Since Dr. Dewar has chosen to suspend his contributory
edification to comp.lang.ada for a while, it is probably
worthwhile to recall one of his most memorable and most
important admonishments about Ada versus other programming
languages.

       "Ada is meant to be more readable than writeable."

A corollary to this is that Ada is intended to be more traceable
than writeable.   Anyone who has had the entertaining experience
of slogging through pages of C or C++ code in search of (yes,
I know there are tools for this) some function or variable knows
the importance of this.

I am not a big fan of use type.   Frankly, I still believe that, for
really well-engineered software, the renaming of the operator
is still a good practice when there is only one.   As an alternative,
renaming the exact operators needed in a child package and
using that is better than a use type clause.

Dot notation serves a very useful purpose.  So does named
association.    In production code on weapon systems, both
are essential.

Toy programs and small programs don't require this kind of
rigor.  Programs that are long-lived and on which we expect
a lot of maintenance do benefit from dot notation.   While it
is more and more common to create software with a brief
lifetime in the Internet world,  this is not so common in the
large-scale software world.



Richard Riehle

Re: Let's change semantics of "use type"

[Victor Porton]

In article <3DD8419F.97C1A8@adaworks.com>,
	Richard Riehle <richard@adaworks.com> writes:
> Victor Porton wrote:
> 
>> I am suggesting (for the next Standard) to change the semantics of "use
>> type" so that it would make visible not only primitive _operators_, but
>> all primitive _operations_.
>>
> 
> We should be cautious about adding features to the Ada
> language that will dilute its essential power.   We should
> be wary of trying to make Ada look like something else
> in pursuit of a potentially ephemeral popularity.  Ada is
> what it is:  a language designed to enable the compiler to
> detect the maximum number of errors as early in the
> development process as possible and to continue catching
> errors during execution and over the full life-cycle of the
> maintenance process.

Well, I now completely agree that changing semantics of
"use type" was a bad idea. Now I am defending only new
"use all type" syntax for this.

[skipped]

"use all type" just introduces something mean between
"use" and dot notation. It is good for mean software systems
between small systems and large scale systems (about which
you have said).

It seems that "use all type" will increase readability and
decrease number of bugs, as I seem that programmers will
tend to "use all type" namely instead of just "use".

So I see no any real arguments against "use all type"
proposal except of a _little_ work of compiler vendors.

Well, now the time to stop the discussion. Seemingly we
have said all. I hope to find time to propose this
officially.