Re: Rational for not making cursor tagged in Containers

[Adam Beneschan <adam@irvine.com>]

On Apr 24, 1:19 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On 24 Apr 2007 09:27:37 -0700, Adam Beneschan wrote:
>
>
>
> > On Apr 24, 3:43 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
>
> >>>>> X, Y : GUI_Boolean;
>
> >>>>> If you say X = Y, does it compare just the values, or does it compare
> >>>>> the discriminants also?
>
> >>>> That depends on how equality operation were defined for the given type. In
> >>>> the concrete case of GUI_Boolean, the user-defined "=" would raise
> >>>> Constraint_Error if at least one of the discriminants is false.
>
> >>> OK, I've got it.
>
> >>>    function "=" (X, Y : GUI_Boolean) return Boolean is
> >>>    begin
> >>>       if not X.Defined or else not Y.Defined then
> >>>          raise Constraint_Error;
> >>>       else
> >>>          return X = Y;
> >>>       end if;
> >>>     end "=";
>
> >>> Is that how you thought this user-defined "=" would be written?
>
> >> Yup, the predefined "=" should be renamed first.
>
> > So a user-defined  "=" that causes a stack overflow due to infinite
> > recursion doesn't bother you?
> > You still don't see the issue, do you?
>
> Which issue? As I said if you want to get at the predefined "=" you have to
> rename it first:

OK, I didn't understand what you meant.  But that begs my original
question:

>>>>>> If you say X = Y, does it compare just the values, or does it compare
>>>>>> the discriminants also?

Your answer to that didn't really answer the question about predefined
equality, but went into some stuff about user-defined equality.  So
we're back where we started.  Does the predefined equality compare
just the values, or does it compare the discriminants also?

Now, it looks like you're saying it would compare just the values, in
order to make this user-defined equality work... well, now, you're
introducing an inconsistency.  The predefined equality on discriminant
record types compares the discriminants.  But predefined equality on
your discriminant scalar types doesn't.  Or else, if it does, that
will work in this particular case---but for more general uses of this
discriminant scalar thing, one may still need the ability to test the
values for equality, without also comparing the discriminants, in
order to *write* a user-defined "=" for the type---and you still
haven't provided a way to do that.


> >> I don't see any problems with generation of a predefined "=" and literals
> >> (True, False). [True is a literal of the type GUI_Boolean, with all
> >> consequences of that.]
>
> > If True has type GUI_Boolean, then it must have a "Defined"
> > discriminant.
>
> It does (the GUI_Boolean returned by the literal has it).
>
> > What is True.Defined?  How does the programmer indicate
> > what it would be?  (And if you say that True.Defined is "true" because
> > "true" is a defined value, then you still don't get it---the Ada
> > language isn't going to know that, and you're going to need a way to
> > tell it that.)
>
> True is a literal. The rule is quite simple. If the literal is not abstract
> and not overridden then its discriminants are defined by the corresponding
> default expressions.
>
> If absence of aggregates was your concern, that is not a problem either:
>
> function Undefined return GUI_Boolean is
>    Result : GUI_Boolean (False);
> begin
>    return Result;
> end Undefined:

Hmmm...  OK, I see how that might work in that particular case.
However, that does make it seem that, although your idea about putting
discriminants on enumeration literals seems like a nice general idea,
it won't work unless there is only one possible value for the
discriminant for which the enumeration value makes any sense.  That's
the case for your GUI_Boolean example---if Defined=True, the
enumeration part of the value can be used, and if Defined=False, the
enumeration part is meaningless.  That's not very general, though.
Suppose, for example, you wanted a GUI_Boolean with three states:
Not_Defined, Defined_By_Config, Defined_By_User, where the latter two
states would distinguish whether a Boolean value were set by some
default present in a configuration file (or the Winodws registry,
say), or were explicitly entered by the user.  Now you can't really do
this, without adding extra syntax and semantics to the language:

   type GUI_State is (Not_Defined, Defined_By_Config,
Defined_By_User);
   type GUI_Boolean (State : GUI_State := ???) is (False, True);

Whichever value you pick for the default State---Defined_By_Config or
Defined_By_User---you don't have a way to set up a GUI_Boolean whose
state is the other one and whose value is one of the False/True
literals.

I'm not going to spend any more time on this thread---I've spent too
much already.  But I'm convinced that (1) nobody will want to add this
feature to the language if the only possible use would be a "Defined"
setup like in your example, and (2) the work required to add extra
syntax, semantics, etc., to make this a more general feature would not
be worthwhile, when discriminant records can so easily be used to
accomplish the same thing and in a way that's easily understandable.

                                    -- Adam