enumeration type

enumeration type

[Rick Santa-Cruz]

Hi,

I have defined a new type in my program:
type Boolean is (True, Maybe, False);

Now I wanna use the standard type, that means Standard.Boolean.
How can I now access the True-element from the original Standard.Boolean
type? For example if I want to write something like:
X : Standard.Boolean;

if X = Standard.Boolean.True then
....
I know that such doesn't work in ada, but how can I access the elements of
an enumeration directly with the full qualified name?

Thanks in advance for your help,
Rick

Re: enumeration type

[Jack Flynn]

"Rick Santa-Cruz" <rick_santa_cruz75@msn.com> wrote in message 
news:cj7lvp$ao3$00$1@news.t-online.com...
> > I know that such doesn't work in ada, but how can I access the elements 
> > of
> an enumeration directly with the full qualified name?

your post indicates function so try something along these lines:

procedure p is

   type fuzzy is (false,maybe,true);

   function "=" (f : fuzzy;

                           b : boolean) return boolean;

   function "=" (f : fuzzy;

                           b : boolean) return boolean is


   begin

      case f is

         when true =>

            return b;

         when false =>

            return not b;

         when maybe =>

            return false;-- or use more complicated parameterized function 
call

      end case;


   end "=";

   zadeh : fuzzy := maybe;

   good : boolean;

begin

   good := (zadeh = standard.false) and not (zadeh = standard.true);

end p;


>
> Thanks in advance for your help,
> Rick
>
> 

Re: enumeration type

[Stephen Leake]

"Rick Santa-Cruz" <rick_santa_cruz75@msn.com> writes:

> Hi,
> 
> I have defined a new type in my program:
> type Boolean is (True, Maybe, False);
> 
> Now I wanna use the standard type, that means Standard.Boolean.
> How can I now access the True-element from the original Standard.Boolean
> type? For example if I want to write something like:
> X : Standard.Boolean;
> 
> if X = Standard.Boolean.True then

if X = Standard.True then

> ....
> I know that such doesn't work in ada, but how can I access the elements of
> an enumeration directly with the full qualified name?
> 
> Thanks in advance for your help,
> Rick
> 
> 
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada-france.org
> http://www.ada-france.org/mailman/listinfo/comp.lang.ada
> 

-- 
-- Stephe

Re: enumeration type

[Dmitry A. Kazakov]

On Mon, 27 Sep 2004 02:13:27 +0200, Rick Santa-Cruz wrote:

> I have defined a new type in my program:
> type Boolean is (True, Maybe, False);
> 
> Now I wanna use the standard type, that means Standard.Boolean.
> How can I now access the True-element from the original Standard.Boolean
> type? For example if I want to write something like:
> X : Standard.Boolean;
> 
> if X = Standard.Boolean.True then

if X then -- (:-))

BTW, the type you define is technically not Boolean. It is better to call
it Logical or Three_State_Logical.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: enumeration type

[Larry Hazel]

Dmitry A. Kazakov wrote:
> On Mon, 27 Sep 2004 02:13:27 +0200, Rick Santa-Cruz wrote:
> 
> 
>>I have defined a new type in my program:
>>type Boolean is (True, Maybe, False);
>>
>>Now I wanna use the standard type, that means Standard.Boolean.
>>How can I now access the True-element from the original Standard.Boolean
>>type? For example if I want to write something like:
>>X : Standard.Boolean;
>>
>>if X = Standard.Boolean.True then
> 
> 
> if X then -- (:-))
> 
> BTW, the type you define is technically not Boolean. It is better to call
> it Logical or Three_State_Logical.
> 
How about Illogical :)

Re: enumeration type

[Dmitry A. Kazakov]

On Mon, 27 Sep 2004 08:40:29 -0500, Larry Hazel wrote:

> Dmitry A. Kazakov wrote:
>> On Mon, 27 Sep 2004 02:13:27 +0200, Rick Santa-Cruz wrote:
>> 
>>>I have defined a new type in my program:
>>>type Boolean is (True, Maybe, False);
>>>
>>>Now I wanna use the standard type, that means Standard.Boolean.
>>>How can I now access the True-element from the original Standard.Boolean
>>>type? For example if I want to write something like:
>>>X : Standard.Boolean;
>>>
>>>if X = Standard.Boolean.True then
>> 
>> if X then -- (:-))
>> 
>> BTW, the type you define is technically not Boolean. It is better to call
>> it Logical or Three_State_Logical.
>> 
> How about Illogical :)

Hey, it is a decent mathematical theory! (:-))

It becomes really nasty with fuzzy logic. In my fuzzy sets implementation
truth levels are fixed point:

Confidence_Size : constant := 8; -- One byte per value
type Confidence is delta 2.0 ** (-Confidence_Size) range 0.0..1.0;
for Confidence'Size use Confidence_Size;

Alas, though as expected, 1.0 /= Confidence'Last!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: enumeration type

[Peter Hermann]

Rick Santa-Cruz <rick_santa_cruz75@msn.com> wrote:
> type Boolean is (True, Maybe, False);

I do not recommend to overload the type boolean.

Furthermore I recommend to use the same "bit pattern"
of internal representation similar to boolean
in case of future hardware-related usefulness, e.g.

type fuzzy is (false,true,maybe);

and now a final joke:

> if X = Standard.Boolean.True then

(-:         if x then           :-)

-- 
--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: enumeration type

[Georg Bauhaus]

Peter Hermann <ica2ph@sinus.csv.ica.uni-stuttgart.de> wrote:
 
: type fuzzy is (false,true,maybe);
: 
: and now a final joke:
: 
:> if X = Standard.Boolean.True then
: 
: (-:         if x then           :-)

:)

If you don't dislike writing down what you want to say,
you can use qualified notation:

procedure p is
   type Ternary_Logical is (True, Maybe, False);
   v: Ternary_Logical;
   b: Boolean;
begin
   if b = Boolean'(True) and v = Ternary_Logical'(True) then
      null;
   end if;
end p;


-- Georg

Re: enumeration type

[Dmitry A. Kazakov]

On Mon, 27 Sep 2004 12:51:27 +0000 (UTC), Georg Bauhaus wrote:

> Peter Hermann <ica2ph@sinus.csv.ica.uni-stuttgart.de> wrote:
>  
>: type fuzzy is (false,true,maybe);
>: 
>: and now a final joke:
>: 
>:> if X = Standard.Boolean.True then
>: 
>: (-:         if x then           :-)
> 
> :)
> 
> If you don't dislike writing down what you want to say,
> you can use qualified notation:
> 
> procedure p is
>    type Ternary_Logical is (True, Maybe, False);
>    v: Ternary_Logical;
>    b: Boolean;
> begin
>    if b = Boolean'(True) and v = Ternary_Logical'(True) then
>       null;
>    end if;
> end p;

What for?

Either

   if b = True and v = True then ...
or
   if b and v = True then ...

is unambiguous.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: enumeration type

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
:> If you don't dislike writing down what you want to say,
:> you can use qualified notation:


:>    if b = Boolean'(True) and v = Ternary_Logical'(True) then

: What for?

Rick asked,
"How can I now access the True-element from the original Standard.Boolean
type?"

Then, sometimes it is not necessary to stress that v is of type
Ternary_Logical or b of type Boolean, or to mention True at all
as in Peter Hermann's example. Sometimes added qualification
helps (me) understanding the software if there is some redundant
type information, because it reduces the need to look at context.

For example, if your function returns a value of record type Foo,
you could write

   return (bar => 7, baz => comp_result);

or
   return Foo'(bar => 7,
               baz => comp_result);  (*)

or 
   return (7, comp_result);		(**)

or
   return Foo'(7, comp_result);

In cases ** is just fine for me, in other cases I like * because
it unambiguously tells me, the reader, what is returned.

Aggregates must be qualified in SPARK, iirc.


-- Georg

Re: enumeration type

[Dmitry A. Kazakov]

On Mon, 27 Sep 2004 14:19:03 +0000 (UTC), Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>:> If you don't dislike writing down what you want to say,
>:> you can use qualified notation:
>
>:>    if b = Boolean'(True) and v = Ternary_Logical'(True) then
> 
>: What for?
> 
> Rick asked,
> "How can I now access the True-element from the original Standard.Boolean
> type?"
> 
> Then, sometimes it is not necessary to stress that v is of type
> Ternary_Logical or b of type Boolean, or to mention True at all
> as in Peter Hermann's example. Sometimes added qualification
> helps (me) understanding the software if there is some redundant
> type information, because it reduces the need to look at context.

Yes, but fundamental literals like numbers, strings, and logical values
too, tend to overload each other. In case of logical literals it is because
True is same in both(all) logics. Three-state logic is a continuation of
Boolean logic.

It is very rare when somebody would really need to fully qualify literals.
Like in:

function "and" (Left, Right : Ternary_Logical)
   return Ternary_Logical;
function "and" (Left : Boolean, Right : Ternary_Logical)
   return Ternary_Logical;
function "and" (Left : Ternary_Logical, Right : Boolean)
   return Ternary_Logical;

function Read (File : File_Type) return Boolean;
function Read (File : File_Type) return Ternary_Logical;

X : Ternary_Logical := Read (File) and Read (File); -- Ambiguous

Which is a bad style anyway.

> For example, if your function returns a value of record type Foo,
> you could write
> 
>    return (bar => 7, baz => comp_result);
> 
> or
>    return Foo'(bar => 7,
>                baz => comp_result);  (*)
> 
> or 
>    return (7, comp_result);		(**)
> 
> or
>    return Foo'(7, comp_result);
> 
> In cases ** is just fine for me, in other cases I like * because
> it unambiguously tells me, the reader, what is returned.
> 
> Aggregates must be qualified in SPARK, iirc.

It is a valid point, but is not applicable for non-composite types.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: enumeration type

[Georg Bauhaus]

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

 [qualification]

: It is a valid point, but is not applicable for non-composite types.

From a technical point of view, yes, you needn't always qualify
literals, sure. From a stylistic point of view, a redundant
qualification might turn out to be a useful reminder, at least when
the near context isn't providing enough information.

Similarly, named parameters can be very helpful. Not only to provide
more information about the desired associations to the compiler,
but also to remind the reader which Insert parameter is the key,
and which is the value in an Integer -> Integer mapping.

Notice how the context for understanding the parameter associations
n this case is far away in the declaration of the library procedure
Insert.

Where is the threshold for "not enough context nearby"?
The psychologists seem to say that between 3 and 7 items
can be stacked by an average person. Would this be guidance
in determining when there are so many "programming constructs"
between two pieces of program text to that the second piece
should be qualified? 


-- Georg