* Enumeration literal visibility and use type
@ 1998-05-26 0:00 William Bralick
1998-05-26 0:00 ` John McCabe
` (2 more replies)
0 siblings, 3 replies; 28+ messages in thread
From: William Bralick @ 1998-05-26 0:00 UTC (permalink / raw)
Greetings!
By now I have convinced myself that the following does not work as I had
hoped:
-- we are provided the following package and required to use it to
-- interface with other subsystems
package doodah is
type state_value_type is (state0, state1, state2, state_etc);
-- and just to make things interesting, let's create a useful message
type useful_message is record
state_stuff : state_value_type;
other_stuff : natural;
end record;
end doodah;
---
with doodah;
procedure test is
use type doodah.cool_type;
a_cool_message : useful_message;
begin
a_cool_message.state_stuff := state0; -- SIRENS WAIL, LIGHTS FLASH
-- COMPILER WANTS:
-- doodah.state0
...
end test;
---
For some reason that I have yet to fathom, I had convinced myself
that "use type" would give immediate visibility of the enumerals in
doodah.cool_type. I am now convinced that it doesn't (though I am
ready to argue that it _should_).
Because sharing this information with my other team members will require
that I eat more than a little crow ;-), I am looking for a pointer to
any information (chapter and verse in the rationale, an AI, anything ...)
that would explain _why_ Ada95 does not provide immediate visibility to
enumeration types that have been the object of a "use type" clause.
Thanks and best regards,
--
Will Bralick ............_/......._/__/..._/.......__/..._____/
........._/....._/_/._/.._/......_/._/.._/..._/
........................._/..._/______/._/...________/._/___/
........._/._/_/....._/_/...._/....._/_/.._/
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Enumeration literal visibility and use type
1998-05-26 0:00 Enumeration literal visibility and use type William Bralick
@ 1998-05-26 0:00 ` John McCabe
1998-05-26 0:00 ` David C. Hoos, Sr.
1998-05-26 0:00 ` Roger Racine
1998-05-26 0:00 ` Matthew Heaney
2 siblings, 1 reply; 28+ messages in thread
From: John McCabe @ 1998-05-26 0:00 UTC (permalink / raw)
bralick@seas.smu.edu (William Bralick) wrote:
>package doodah is
>
> type state_value_type is (state0, state1, state2, state_etc);
>
> -- and just to make things interesting, let's create a useful message
>
> type useful_message is record
> state_stuff : state_value_type;
> other_stuff : natural;
> end record;
>
>end doodah;
There is no "cool_type". There is "state_value_type" and
"useful_message", so you're "use type doodah.cool_type" will never work
for a start.
>For some reason that I have yet to fathom, I had convinced myself
>that "use type" would give immediate visibility of the enumerals in
>doodah.cool_type. I am now convinced that it doesn't (though I am
>ready to argue that it _should_).
Despite the obvious error, the "use type" clause is designed to provide
visibility to the OPERATORS of the type, NOT the type itself so the
behaviour you are seeing is correct.
--
Best Regards
John McCabe
=====================================================================
Any opinions expressed are mine and based on my own experience. They
should in no way be taken as the opinion of anyone I am currently
working with, or of the company I am currently working for.
If you have a problem with anything I say, SPEAK TO ME!
=====================================================================
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Enumeration literal visibility and use type
1998-05-26 0:00 ` John McCabe
@ 1998-05-26 0:00 ` David C. Hoos, Sr.
1998-05-26 0:00 ` John English
` (3 more replies)
0 siblings, 4 replies; 28+ messages in thread
From: David C. Hoos, Sr. @ 1998-05-26 0:00 UTC (permalink / raw)
John McCabe wrote in message <6kejt5$75u@gcsin3.geccs.gecm.com>...
>bralick@seas.smu.edu (William Bralick) wrote:
>
>Despite the obvious error, the "use type" clause is designed to provide
>visibility to the OPERATORS of the type, NOT the type itself so the
>behaviour you are seeing is correct.
>
John is correct. The only way I've found to make the literals visible
(without
a context clause "use doodah;") is in the units requiring visibility is to
declare:
state_0 : constant doodah.state_value_type := doodah.state_0;
.
.
.
state_etc : constant doodah.state_value_type := doodah.state_etc;
Anyone have a better way?
David C. Hoos, Sr.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Enumeration literal visibility and use type
1998-05-26 0:00 ` David C. Hoos, Sr.
@ 1998-05-26 0:00 ` John English
1998-05-26 0:00 ` Ray Blaak
` (2 subsequent siblings)
3 siblings, 0 replies; 28+ messages in thread
From: John English @ 1998-05-26 0:00 UTC (permalink / raw)
David C. Hoos, Sr. (david.c.hoos.sr@ada95.com) wrote:
: John McCabe wrote in message <6kejt5$75u@gcsin3.geccs.gecm.com>...
: John is correct. The only way I've found to make the literals visible
: (without
: a context clause "use doodah;") is in the units requiring visibility is to
: declare:
: state_0 : constant doodah.state_value_type := doodah.state_0;
: .
: .
: .
: state_etc : constant doodah.state_value_type := doodah.state_etc;
: Anyone have a better way?
Dunno about "better", but I can do "different"... ;-)
function state_0 return doodah.state_value_type renames doodah.state_0;
-- etc. etc.
(but of course I'd use Capitalised_Identifiers :-)
-----------------------------------------------------------------
John English | mailto:je@brighton.ac.uk
Senior Lecturer | http://www.it.bton.ac.uk/staff/je
Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS **
University of Brighton | -- see http://burks.bton.ac.uk
-----------------------------------------------------------------
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Enumeration literal visibility and use type
1998-05-26 0:00 ` David C. Hoos, Sr.
1998-05-26 0:00 ` John English
@ 1998-05-26 0:00 ` Ray Blaak
1998-05-27 0:00 ` John McCabe
1998-05-26 0:00 ` Matthew Heaney
1998-05-27 0:00 ` Robert Dewar
3 siblings, 1 reply; 28+ messages in thread
From: Ray Blaak @ 1998-05-26 0:00 UTC (permalink / raw)
"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:
>John is correct. The only way I've found to make the literals visible
>(without a context clause "use doodah;") is in the units requiring
>visibility is to declare:
>state_0 : constant doodah.state_value_type := doodah.state_0;
>Anyone have a better way?
I like doing:
package doodah is
package State is
type Value is (state0, state1, ...);
end State;
...
end doodah;
with doodah;
procedure Main is
use doodah.State;
cool : doodah.State.Value := state0;
begin
end Main;
Another approach, especially when you only need the literals in a case
statement, is to do:
package doodah is
type state_value is (state0, ...);
...
end doodah;
with doodah;
procedure Report_State(The_State : in doodah.state_value) is
type states is new doodah.state_value; -- literals are now in scope
begin
case states(The_State) is
when state0 => ...;
when state1 => ...;
...
end case;
end Report_State;
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
blaak@infomatch.com The Rhythm has my soul.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Enumeration literal visibility and use type
1998-05-26 0:00 ` Ray Blaak
@ 1998-05-27 0:00 ` John McCabe
1998-05-27 0:00 ` John McCabe
0 siblings, 1 reply; 28+ messages in thread
From: John McCabe @ 1998-05-27 0:00 UTC (permalink / raw)
To: blaak
(Ray Blaak) wrote:
>
>The Rhythm is around me,
>The Rhythm has control.
>The Rhythm is inside me,
>The Rhythm has my soul.
He was brilliant then - I went to see him at the Glasgow Apollo that
year.
--
Best Regards
John McCabe
<john@nospam.assen.demon.co.uk> <- use this for emailblaak@infomatch.com
=====================================================================
Any opinions expressed are mine and based on my own experience. They
should in no way be taken as the opinion of anyone I am currently
working with, or of the company I am currently working for.
If you have a problem with anything I say, SPEAK TO ME!
(remove "nospam." to reply by e-mail)
=====================================================================
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Enumeration literal visibility and use type
1998-05-27 0:00 ` John McCabe
@ 1998-05-27 0:00 ` John McCabe
0 siblings, 0 replies; 28+ messages in thread
From: John McCabe @ 1998-05-27 0:00 UTC (permalink / raw)
OOPS
That was meant to be email only but I forgot to take the newsgroup name
out of the header!
Netscape 1.22 - What a newsreader - NOT!
Sorry
--
Best Regards
John McCabe
=====================================================================
Any opinions expressed are mine and based on my own experience. They
should in no way be taken as the opinion of anyone I am currently
working with, or of the company I am currently working for.
If you have a problem with anything I say, SPEAK TO ME!
(remove "nospam." to reply by e-mail)
=====================================================================
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Enumeration literal visibility and use type
1998-05-26 0:00 ` David C. Hoos, Sr.
1998-05-26 0:00 ` John English
1998-05-26 0:00 ` Ray Blaak
@ 1998-05-26 0:00 ` Matthew Heaney
1998-05-27 0:00 ` John McCabe
1998-05-27 0:00 ` Robert Dewar
3 siblings, 1 reply; 28+ messages in thread
From: Matthew Heaney @ 1998-05-26 0:00 UTC (permalink / raw)
"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> writes:
> >Despite the obvious error, the "use type" clause is designed to provide
> >visibility to the OPERATORS of the type, NOT the type itself so the
> >behaviour you are seeing is correct.
> >
> John is correct. The only way I've found to make the literals visible
> (without
> a context clause "use doodah;") is in the units requiring visibility is to
> declare:
>
> state_0 : constant doodah.state_value_type := doodah.state_0;
> .
> .
> .
> state_etc : constant doodah.state_value_type := doodah.state_etc;
> Anyone have a better way?
Yes. Do a use immediately after declaring the object:
declare
State : Doodah.State_Value_Type;
use Doodah;
begin
<literals are now directly visible>
State := State_0;
end;
The idea is that you want to be able to trace an entity back to the
source. Since you've stated explicitly that State_Value_Type is
declared in Doodah, there is high probability that State_0 is declared
there too.
Matt
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Enumeration literal visibility and use type
1998-05-26 0:00 ` Matthew Heaney
@ 1998-05-27 0:00 ` John McCabe
0 siblings, 0 replies; 28+ messages in thread
From: John McCabe @ 1998-05-27 0:00 UTC (permalink / raw)
Matthew Heaney <matthew_heaney@acm.org> wrote:
>> Anyone have a better way?
>
>
>Yes. Do a use immediately after declaring the object:
>
>declare
> State : Doodah.State_Value_Type;
> use Doodah;
>begin
> <literals are now directly visible>
> State := State_0;
>end;
>
>The idea is that you want to be able to trace an entity back to the
>source. Since you've stated explicitly that State_Value_Type is
>declared in Doodah, there is high probability that State_0 is declared
>there too.
But here you are still bringing far more than State_Value_Type and its
operators into scope in the block which is what William is trying to
avoid.
If the block was simple then that could be a way to do it, and I have
done it myself that way before. But if it is complicated, the declare
section could easily get lost in the noise in a printout, leaving it only
very slightly clearer than "use"ing doodah at the outer level.
--
Best Regards
John McCabe
<john@nospam.assen.demon.co.uk>
=====================================================================
Any opinions expressed are mine and based on my own experience. They
should in no way be taken as the opinion of anyone I am currently
working with, or of the company I am currently working for.
If you have a problem with anything I say, SPEAK TO ME!
(remove "nospam." to reply by e-mail)
=====================================================================
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Enumeration literal visibility and use type
1998-05-26 0:00 ` David C. Hoos, Sr.
` (2 preceding siblings ...)
1998-05-26 0:00 ` Matthew Heaney
@ 1998-05-27 0:00 ` Robert Dewar
1998-05-27 0:00 ` Matthew Heaney
3 siblings, 1 reply; 28+ messages in thread
From: Robert Dewar @ 1998-05-27 0:00 UTC (permalink / raw)
<<state_0 : constant doodah.state_value_type := doodah.state_0;
.
.
.
state_etc : constant doodah.state_value_type := doodah.state_etc;
Anyone have a better way?
>>
Sure! Use a normal use clause on the package. If you like isolate
the type in its own package, so the scope of the use clause is
limited to the type.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Enumeration literal visibility and use type
1998-05-26 0:00 Enumeration literal visibility and use type William Bralick
1998-05-26 0:00 ` John McCabe
@ 1998-05-26 0:00 ` Roger Racine
1998-05-26 0:00 ` Matthew Heaney
2 siblings, 0 replies; 28+ messages in thread
From: Roger Racine @ 1998-05-26 0:00 UTC (permalink / raw)
In article <6kej65$dnh$1@hermes.seas.smu.edu> bralick@seas.smu.edu (William
Bralick) writes:
>By now I have convinced myself that the following does not work as I had
>hoped:
>-- we are provided the following package and required to use it to
>-- interface with other subsystems
>package doodah is
> type state_value_type is (state0, state1, state2, state_etc);
> -- and just to make things interesting, let's create a useful message
> type useful_message is record
> state_stuff : state_value_type;
> other_stuff : natural;
> end record;
>end doodah;
>---
>with doodah;
>procedure test is
> use type doodah.cool_type;
> a_cool_message : useful_message;
>begin
> a_cool_message.state_stuff := state0; -- SIRENS WAIL, LIGHTS FLASH
> -- COMPILER WANTS:
> -- doodah.state0
> ...
>end test;
>---
>For some reason that I have yet to fathom, I had convinced myself
>that "use type" would give immediate visibility of the enumerals in
>doodah.cool_type. I am now convinced that it doesn't (though I am
>ready to argue that it _should_).
Section 8.4 of the Ada RM:
"a use_type_clause achieves direct visibility of the
primitive operators of a type."
Enumeration literals are not operators.
Roger Racine
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Enumeration literal visibility and use type
1998-05-26 0:00 Enumeration literal visibility and use type William Bralick
1998-05-26 0:00 ` John McCabe
1998-05-26 0:00 ` Roger Racine
@ 1998-05-26 0:00 ` Matthew Heaney
1998-05-27 0:00 ` John McCabe
` (2 more replies)
2 siblings, 3 replies; 28+ messages in thread
From: Matthew Heaney @ 1998-05-26 0:00 UTC (permalink / raw)
bralick@seas.smu.edu (William Bralick) writes:
> For some reason that I have yet to fathom, I had convinced myself
> that "use type" would give immediate visibility of the enumerals in
> doodah.cool_type. I am now convinced that it doesn't (though I am
> ready to argue that it _should_).
>
> Because sharing this information with my other team members will require
> that I eat more than a little crow ;-), I am looking for a pointer to
> any information (chapter and verse in the rationale, an AI, anything ...)
> that would explain _why_ Ada95 does not provide immediate visibility to
> enumeration types that have been the object of a "use type" clause.
No, use type will NOT give you direct visibility to the enumeration literals.
I helps to understand the type model wrt to enumeration types. In Ada,
an enumeration literal is modeled as a "primitive operation" of the
type. Given this declaration,
type T is (E1, E2, E3);
it's as if it were declared like this:
type T;
function E1 return T;
function E2 return T;
function E3 return T;
The reason for this is that it allows different enumeration types in the
same scope to have the same values for literals, ie
type T2 is (E2, E3, E4);
O1 : T1 := E2;
O2 : T2 := E2;
The model is that E2 is a parameterless function returning a value of
the type. Since each type is different, each "function" is different,
and so there is no confusion about what E2 means. The usual name
resolution rules apply.
The issue is that "use type" only gives you direct visibility to the
predefined "operators" of a type; it does not give you direct visibility
to the predefined "operations" of a type. Enumeration literals are
operations, not operators, and so aren't made directly visible by "use
type."
Does that explain it?
Matt
P.S. Here's another example to illustrate how enumeration types work.
Given this declaration,
generic
type T is private;
function F return T;
package GP is ...;
I can instantiate it using an enumeration literal, passing it as the
generic actual "function":
package P is new GP (T, E2);
Pretty cool, eh?
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Enumeration literal visibility and use type
1998-05-26 0:00 ` Matthew Heaney
@ 1998-05-27 0:00 ` John McCabe
1998-05-27 0:00 ` Mats Weber
1998-05-27 0:00 ` William Bralick
2 siblings, 0 replies; 28+ messages in thread
From: John McCabe @ 1998-05-27 0:00 UTC (permalink / raw)
Matthew Heaney <matthew_heaney@acm.org> wrote:
>
>P.S. Here's another example to illustrate how enumeration types work.
>Given this declaration,
>
<..snip..>
>
>Pretty cool, eh?
That's a matter of opinion (although it certainly explains John English's
comment which I didn't originally understand). That's a bit like saying
the conditional statement:
x = (y>z) ? z : y;
makes sense if you ask me!
--
Best Regards
John McCabe
<john@nospam.assen.demon.co.uk>
=====================================================================
Any opinions expressed are mine and based on my own experience. They
should in no way be taken as the opinion of anyone I am currently
working with, or of the company I am currently working for.
If you have a problem with anything I say, SPEAK TO ME!
(remove "nospam." to reply by e-mail)
=====================================================================
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Enumeration literal visibility and use type
1998-05-26 0:00 ` Matthew Heaney
1998-05-27 0:00 ` John McCabe
@ 1998-05-27 0:00 ` Mats Weber
1998-05-27 0:00 ` William Bralick
2 siblings, 0 replies; 28+ messages in thread
From: Mats Weber @ 1998-05-27 0:00 UTC (permalink / raw)
> The issue is that "use type" only gives you direct visibility to the
> predefined "operators" of a type; it does not give you direct visibility
^^^^^^^^^^ primitive
> to the predefined "operations" of a type. Enumeration literals are
> operations, not operators, and so aren't made directly visible by "use
> type."
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Enumeration literal visibility and use type
1998-05-26 0:00 ` Matthew Heaney
1998-05-27 0:00 ` John McCabe
1998-05-27 0:00 ` Mats Weber
@ 1998-05-27 0:00 ` William Bralick
2 siblings, 0 replies; 28+ messages in thread
From: William Bralick @ 1998-05-27 0:00 UTC (permalink / raw)
In article <m3btsk8xoa.fsf@mheaney.ni.net>,
Matthew Heaney <matthew_heaney@acm.org> wrote:
|
|No, use type will NOT give you direct visibility to the enumeration literals.
Acknowledged.
|...
|The issue is that "use type" only gives you direct visibility to the
|predefined "operators" of a type; it does not give you direct visibility
|to the predefined "operations" of a type. Enumeration literals are
|operations, not operators, and so aren't made directly visible by "use
|type."
I think that this is the key point where my confusion arose.
I recall understanding the concept of enumerals being parameterless
functions and I guess that I conflated them with the concept of
"operators" perhaps because I was simultaneously dealing with the
definition of "primitive operations" and "primitive subprograms"
which, of course, include operators ...
Oh, well.
|Does that explain it?
Yes, thanks. You have all been most helpful ...
Best regards,
--
Will Bralick ............_/......._/__/..._/.......__/..._____/
........._/....._/_/._/.._/......_/._/.._/..._/
........................._/..._/______/._/...________/._/___/
.............__/_/......._______/.......__/..._/
^ permalink raw reply [flat|nested] 28+ messages in thread
[parent not found: <6kej65$dnh$1@hermes.seas.smu.edu| <6kejt5$75u@gcsin3.geccs.gecm.com>]
* Re: Enumeration literal visibility and use type
[not found] <6kej65$dnh$1@hermes.seas.smu.edu| <6kejt5$75u@gcsin3.geccs.gecm.com>
@ 1998-05-26 0:00 ` William Bralick
1998-05-26 0:00 ` Fergus Henderson
0 siblings, 1 reply; 28+ messages in thread
From: William Bralick @ 1998-05-26 0:00 UTC (permalink / raw)
In article <6kejt5$75u@gcsin3.geccs.gecm.com|,
John McCabe <jgm@hayling.cwmbran.gecm.com| wrote:
|bralick@seas.smu.edu (William Bralick) wrote:
|
|>package doodah is
|>
|> type state_value_type is (state0, state1, state2, state_etc);
|>
|> -- and just to make things interesting, let's create a useful message
|>
|> type useful_message is record
|> state_stuff : state_value_type;
|> other_stuff : natural;
|> end record;
|>
|>end doodah;
|
|There is no "cool_type". There is "state_value_type" and
|"useful_message", so you're "use type doodah.cool_type" will never work
|for a start.
Hmm ... so much for changing horses (examples) in midstream. Yes, I
obviously intended "use type doodah.state_value_type" where I wrote
"use type doodah.cool_type". Mea culpa.
|>For some reason that I have yet to fathom, I had convinced myself
|>that "use type" would give immediate visibility of the enumerals in
|>doodah.cool_type. I am now convinced that it doesn't (though I am
^^^^^^^^^
state_value_type
|>ready to argue that it _should_).
|
|Despite the obvious error, the "use type" clause is designed to provide
|visibility to the OPERATORS of the type, NOT the type itself so the
|behaviour you are seeing is correct.
Yes ... and I had understood that visibility of the type name was still
restricted (one would always need to write doodah.state_value_type), but
I was convinced that the enumerals themselves would be visible to avoid
(1) the use of the "use clause" or (2) defining a series of named constants.
The latter work-around looks disturbingly like the function renames that
we were avoiding with the use type clause.
So once again, I am merely asking for a reference to some documentation
that might describe _why_ OPERATORS only were made visible and in particular
why enumerals were left in the (somewhat) clumsy Ada'83 form. Perhaps this
was never even considered ... that would be important to know, too.
Anybody?
Best regards,
--
Will Bralick ............_/......._/__/..._/.......__/..._____/
........._/....._/_/._/.._/......_/._/.._/..._/
........................._/..._/______/._/...________/._/___/
........._/._/_/....._/_/...._/....._/_/.._/
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Enumeration literal visibility and use type
1998-05-26 0:00 ` William Bralick
@ 1998-05-26 0:00 ` Fergus Henderson
1998-05-27 0:00 ` William Bralick
1998-05-27 0:00 ` John McCabe
0 siblings, 2 replies; 28+ messages in thread
From: Fergus Henderson @ 1998-05-26 0:00 UTC (permalink / raw)
bralick@seas.smu.edu (William Bralick) writes:
>John McCabe <jgm@hayling.cwmbran.gecm.com| wrote:
>|... the "use type" clause is designed to provide
>|visibility to the OPERATORS of the type, NOT the type itself so the
>|behaviour you are seeing is correct.
>
>Yes ... and I had understood that visibility of the type name was still
>restricted (one would always need to write doodah.state_value_type), but
>I was convinced that the enumerals themselves would be visible to avoid
>(1) the use of the "use clause" or (2) defining a series of named constants.
What's wrong with (3) just using explicit module qualifiers?
>So once again, I am merely asking for a reference to some documentation
>that might describe _why_ OPERATORS only were made visible
Because explicit module qualifiers on OPERATORS look very ugly.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Enumeration literal visibility and use type
1998-05-26 0:00 ` Fergus Henderson
@ 1998-05-27 0:00 ` William Bralick
1998-05-27 0:00 ` John McCabe
1 sibling, 0 replies; 28+ messages in thread
From: William Bralick @ 1998-05-27 0:00 UTC (permalink / raw)
In article <6kf0r3$isj$1@mulga.cs.mu.OZ.AU>,
Fergus Henderson <fjh@cs.mu.oz.au> wrote:
|bralick@seas.smu.edu (William Bralick) writes:
|
|>John McCabe <jgm@hayling.cwmbran.gecm.com| wrote:
|>|... the "use type" clause is designed to provide
|>|visibility to the OPERATORS of the type, NOT the type itself so the
|>|behaviour you are seeing is correct.
|>
|>Yes ... and I had understood that visibility of the type name was still
|>restricted (one would always need to write doodah.state_value_type), but
|>I was convinced that the enumerals themselves would be visible to avoid
|>(1) the use of the "use clause" or (2) defining a series of named constants.
|
|What's wrong with (3) just using explicit module qualifiers?
The scenario is that the package with the enumeration type declared
in it includes other types (but no operations), (2) this package is
not in my control (so I cannot create a subpackage), (3) the names
are quite descriptive (e.g. doodah.thingy_bobber.whatchamacallit),
(4) the standard abbreviations are also not in my control, are cryptic
and require the renames we find obnoxious, viz.
package d_tb_what renames doodah.thingy_bobber.whatchamacallit;
-- note that it is a manual inspection task to ensure that the
-- standard abbreviations are used
whatever : d_tb_what.cool_enumeration_type;
-- or, worse
whatmore : doodah.thingy_bobber.whatchamacallit.cool_enumeration_type;
...
begin
whatever := d_tb_what.state0;
-- or, again worse
whatmore := doodah.thingy_bobber.whatchamacallit.state0;
end test;
|>So once again, I am merely asking for a reference to some documentation
|>that might describe _why_ OPERATORS only were made visible
|
|Because explicit module qualifiers on OPERATORS look very ugly.
I think that a similar argument applies to enumerals. I admit, though,
de gustibus non disputandum est.
Best regards,
--
Will Bralick ............_/......._/__/..._/.......__/..._____/
........._/....._/_/._/.._/......_/._/.._/..._/
........................._/..._/______/._/...________/._/___/
.............__/_/......._______/.......__/..._/
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Enumeration literal visibility and use type
1998-05-26 0:00 ` Fergus Henderson
1998-05-27 0:00 ` William Bralick
@ 1998-05-27 0:00 ` John McCabe
1998-05-27 0:00 ` Peter Amey
1998-05-27 0:00 ` Robert Dewar
1 sibling, 2 replies; 28+ messages in thread
From: John McCabe @ 1998-05-27 0:00 UTC (permalink / raw)
fjh@cs.mu.oz.au (Fergus Henderson) wrote:
>>So once again, I am merely asking for a reference to some documentation
>>that might describe _why_ OPERATORS only were made visible
>
>Because explicit module qualifiers on OPERATORS look very ugly.
And explicit module qualifiers on enumeration literals don't?
--
Best Regards
John McCabe
<john@nospam.assen.demon.co.uk>
=====================================================================
Any opinions expressed are mine and based on my own experience. They
should in no way be taken as the opinion of anyone I am currently
working with, or of the company I am currently working for.
If you have a problem with anything I say, SPEAK TO ME!
(remove "nospam." to reply by e-mail)
=====================================================================
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Enumeration literal visibility and use type
1998-05-27 0:00 ` John McCabe
@ 1998-05-27 0:00 ` Peter Amey
1998-05-27 0:00 ` John McCabe
1998-05-27 0:00 ` Robert Dewar
1 sibling, 1 reply; 28+ messages in thread
From: Peter Amey @ 1998-05-27 0:00 UTC (permalink / raw)
John McCabe wrote:
>
> fjh@cs.mu.oz.au (Fergus Henderson) wrote:
> >>So once again, I am merely asking for a reference to some documentation
> >>that might describe _why_ OPERATORS only were made visible
> >
> >Because explicit module qualifiers on OPERATORS look very ugly.
>
> And explicit module qualifiers on enumeration literals don't?
>
Not if suitable names are chosen. Most of the difficulties with Ada
prefixes and dotted names seem to arise because people fight the
language rather than taking advantage of it. Names should be chosen for
their readability in context. I much prefer:
package Valve is
type T is (Open, Shut);
end Valve;
allowing: DrainValve : Valve.T := Valve.Shut;
to the more common(in my experience) form:
package BasicTypes is
type ValveType is (Open, Shut);
end BasicTypes;
which leads to: DrainValve : BasicTypes.ValveType := BasicTypes.Shut;
which _is_ ugly.
Peter
--
---------------------------------------------------------------------------
__ Peter Amey, Product Manager
) Praxis Critical Systems Ltd
/ 20, Manvers Street, Bath, BA1 1PX
/ 0 Tel: +44 (0)1225 466991
(_/ Fax: +44 (0)1225 469006
http://www.praxis-cs.co.uk/
--------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Enumeration literal visibility and use type
1998-05-27 0:00 ` Peter Amey
@ 1998-05-27 0:00 ` John McCabe
0 siblings, 0 replies; 28+ messages in thread
From: John McCabe @ 1998-05-27 0:00 UTC (permalink / raw)
Peter Amey <pna@praxis-cs.co.uk> wrote:
>Not if suitable names are chosen. Most of the difficulties with Ada
>prefixes and dotted names seem to arise because people fight the
>language rather than taking advantage of it. Names should be chosen for
>their readability in context. I much prefer:
>
>package Valve is
> type T is (Open, Shut);
>end Valve;
>
>allowing: DrainValve : Valve.T := Valve.Shut;
>
That's not a bad point, but if I say:
ValveState : Valve.T := Valve.Shut;
then do some processing then I want to check the state of the valve I
have to do:
if (ValveState = Valve.Shut) then ...
when I would rather just say:
if (ValveState = Shut) then ...
I see the second one as being clearer.
Since "Valve" is alonger word than "Shut" and is the first to be read,
there is a risk of it reducing the "obviousness" of what is intended, and
reducing readability of the code.
--
Best Regards
John McCabe
=====================================================================
Any opinions expressed are mine and based on my own experience. They
should in no way be taken as the opinion of anyone I am currently
working with, or of the company I am currently working for.
If you have a problem with anything I say, SPEAK TO ME!
(remove "nospam." to reply by e-mail)
=====================================================================
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Enumeration literal visibility and use type
1998-05-27 0:00 ` John McCabe
1998-05-27 0:00 ` Peter Amey
@ 1998-05-27 0:00 ` Robert Dewar
1998-05-28 0:00 ` John McCabe
1 sibling, 1 reply; 28+ messages in thread
From: Robert Dewar @ 1998-05-27 0:00 UTC (permalink / raw)
John McCabe says
<<And explicit module qualifiers on enumeration literals don't?
>>
If you think that explicit module qualifiers on identifiers are ugly, then
you definitely want to consider using a real "use" package clause.
Basically what is going on with use type is that there are a significant
number of people who don't mind writing, or even prefer to write:
package_name.identifier;
and of course enumeration literals are just a special case of identifiers.
But they draw the line at
package_name."+" (x,y);
Basically the issue here is that people want to know the package where
something comes from at a glance, and hence don't like use package clauses,
but their desire to see the package where something comes from at a glance
is not strong enough to overcome their disgust at having to go to the ugly
prefix notation for binary operators. It's just a matter of trading off
syntactic ugliness vs explicit qualification.
I always have trouble understanding this distinction, but I *SURELY* cannot
understand that someone would not mind writing:
x := red;
where red is an enuemration literal, but would not want to write
x := colorget;
where colorget is some other function than an enumeration literal. To
want to qualify in the second case:
x := pkg.colorget;
but to object to
x := pkg.red;
seems very inconsistent to me. I do understand the use type argument, but
surely to make it apply to enumeration literals and not other primitive
operations would be very odd indeed.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Enumeration literal visibility and use type
1998-05-27 0:00 ` Robert Dewar
@ 1998-05-28 0:00 ` John McCabe
1998-05-28 0:00 ` Thomas Hood
1998-05-28 0:00 ` Robert Dewar
0 siblings, 2 replies; 28+ messages in thread
From: John McCabe @ 1998-05-28 0:00 UTC (permalink / raw)
dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
>John McCabe says
>
><<And explicit module qualifiers on enumeration literals don't?
>>>
>
>If you think that explicit module qualifiers on identifiers are ugly,
>then you definitely want to consider using a real "use" package clause.
I have no real problem with that personally, and have done so on various
occasions although obviously I have tried to restrict the scope of the
use (package) clause as much as possible.
>Basically what is going on with use type is that there are a significant
>number of people who don't mind writing, or even prefer to write:
>
> package_name.identifier;
>
>and of course enumeration literals are just a special case of
>identifiers. But they draw the line at
>
> package_name."+" (x,y);
I believe it's simply to do with people's expectations.
Naturally (well.. you know what I mean) we expect addition of 2 values to
be represented by x + y, and this is true of most High Level Languages
that I'm aware of, and C. Therefore it simply appears natural to prefer
to see x + y rather than package_name."+"(x,y). (Note: I believe that
both the package name and the ""s tend to distract the reader from the
meaning in these cases).
If Ada didn't allow the use of operators in this way, we would probably
have to write a new function say package_name.sum(x,y) to perform this
operation, but which wouldn't look anywhere near as blatantly unnatural.
>I always have trouble understanding this distinction, but I *SURELY*
<..snip..>
>seems very inconsistent to me. I do understand the use type argument,
>but surely to make it apply to enumeration literals and not other
>primitive operations would be very odd indeed.
I'm not sure what you mean here. Isn't it the primitive operations that
it already applies to? If so, there is no suggestion of it being applied
to only enumeration literals and not to the primitive operations. As far
as I understand it, the question is why doesn't it apply to both?
--
Best Regards
John McCabe
<john@nospam.assen.demon.co.uk>
=====================================================================
Any opinions expressed are mine and based on my own experience. They
should in no way be taken as the opinion of anyone I am currently
working with, or of the company I am currently working for.
If you have a problem with anything I say, SPEAK TO ME!
(remove "nospam." to reply by e-mail)
=====================================================================
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Enumeration literal visibility and use type
1998-05-28 0:00 ` John McCabe
@ 1998-05-28 0:00 ` Thomas Hood
1998-05-28 0:00 ` Robert Dewar
1998-05-28 0:00 ` Robert Dewar
1 sibling, 1 reply; 28+ messages in thread
From: Thomas Hood @ 1998-05-28 0:00 UTC (permalink / raw)
John McCabe wrote:
>
> dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
> >John McCabe says
<snip>
> >
> > package_name."+" (x,y);
>
> I believe it's simply to do with people's expectations.
>
> Naturally (well.. you know what I mean) we expect addition of 2 values to
> be represented by x + y, and this is true of most High Level Languages
> that I'm aware of, and C. Therefore it simply appears natural to prefer
> to see x + y rather than package_name."+"(x,y). (Note: I believe that
> both the package name and the ""s tend to distract the reader from the
> meaning in these cases).
<snip>
My usual Ada83 way around this was to import the operator using a
renames clause.
i.e. function "+"(l,r : my_pkg.my_type) return my_pkg.my_type renames
my_pkg."+";
This allows the infix use of the binary operator. It is still clumsy
and not very pretty but it sure makes the body of the code read better.
Thomas Hood
thomas@ifn.com
thomas@yachtrace.net
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Enumeration literal visibility and use type
1998-05-28 0:00 ` Thomas Hood
@ 1998-05-28 0:00 ` Robert Dewar
0 siblings, 0 replies; 28+ messages in thread
From: Robert Dewar @ 1998-05-28 0:00 UTC (permalink / raw)
Thomas said
<<My usual Ada83 way around this was to import the operator using a
renames clause.
i.e. function "+"(l,r : my_pkg.my_type) return my_pkg.my_type renames
my_pkg."+";
This allows the infix use of the binary operator. It is still clumsy
and not very pretty but it sure makes the body of the code read better.
>>
You and x zillion other Ada 83 programmers, this is indeed an absolutely
standard technique among those who do not like to use "use".
And it is EXACTLY this stuff that "use type" was designed to consign to
the rubbish bin!
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Enumeration literal visibility and use type
1998-05-28 0:00 ` John McCabe
1998-05-28 0:00 ` Thomas Hood
@ 1998-05-28 0:00 ` Robert Dewar
1998-05-29 0:00 ` John McCabe
1 sibling, 1 reply; 28+ messages in thread
From: Robert Dewar @ 1998-05-28 0:00 UTC (permalink / raw)
John McCabe said
<<>seems very inconsistent to me. I do understand the use type argument,
>but surely to make it apply to enumeration literals and not other
>primitive operations would be very odd indeed.
I'm not sure what you mean here. Isn't it the primitive operations that
it already applies to? If so, there is no suggestion of it being applied
to only enumeration literals and not to the primitive operations. As far
as I understand it, the question is why doesn't it apply to both?
>>
You are getting confused by the terminology. Primitive operations refers
to all functions and procedures defined with a parameter or return type
of the type. You read "operators" for operations. use type refers ONLY
to operators, not to all primitive operations.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Enumeration literal visibility and use type
1998-05-28 0:00 ` Robert Dewar
@ 1998-05-29 0:00 ` John McCabe
0 siblings, 0 replies; 28+ messages in thread
From: John McCabe @ 1998-05-29 0:00 UTC (permalink / raw)
dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
>John McCabe said
Blah blah ... primitive operations...
>
>You are getting confused by the terminology.
You are quite correct. Thank you for clearing up my confusion.
--
Best Regards
John McCabe
<john@nospam.assen.demon.co.uk>
=====================================================================
Any opinions expressed are mine and based on my own experience. They
should in no way be taken as the opinion of anyone I am currently
working with, or of the company I am currently working for.
If you have a problem with anything I say, SPEAK TO ME!
(remove "nospam." to reply by e-mail)
=====================================================================
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~1998-05-29 0:00 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-05-26 0:00 Enumeration literal visibility and use type William Bralick
1998-05-26 0:00 ` John McCabe
1998-05-26 0:00 ` David C. Hoos, Sr.
1998-05-26 0:00 ` John English
1998-05-26 0:00 ` Ray Blaak
1998-05-27 0:00 ` John McCabe
1998-05-27 0:00 ` John McCabe
1998-05-26 0:00 ` Matthew Heaney
1998-05-27 0:00 ` John McCabe
1998-05-27 0:00 ` Robert Dewar
1998-05-27 0:00 ` Matthew Heaney
1998-05-26 0:00 ` Roger Racine
1998-05-26 0:00 ` Matthew Heaney
1998-05-27 0:00 ` John McCabe
1998-05-27 0:00 ` Mats Weber
1998-05-27 0:00 ` William Bralick
[not found] <6kej65$dnh$1@hermes.seas.smu.edu| <6kejt5$75u@gcsin3.geccs.gecm.com>
1998-05-26 0:00 ` William Bralick
1998-05-26 0:00 ` Fergus Henderson
1998-05-27 0:00 ` William Bralick
1998-05-27 0:00 ` John McCabe
1998-05-27 0:00 ` Peter Amey
1998-05-27 0:00 ` John McCabe
1998-05-27 0:00 ` Robert Dewar
1998-05-28 0:00 ` John McCabe
1998-05-28 0:00 ` Thomas Hood
1998-05-28 0:00 ` Robert Dewar
1998-05-28 0:00 ` Robert Dewar
1998-05-29 0:00 ` John McCabe
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox