Re: Rational for not making cursor tagged in Containers

[Adam Beneschan <adam@irvine.com>]

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?

> > I think you've missed the point.  If you want a feature like this in
> > the language, you can't base the whole semantics on one particular
> > example you happened to come up with (or that you happened to run
> > across a use for when you were working on some particular project).
> > The design of the feature in the language has to be more general than
> > that, and it has to include cases where a discriminant has some
> > meaning other than "This value is defined".
>
> 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.  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.)

> > and as one of my examples hinted at, I don't think the
> > current language syntax is enough to handle this without some pretty
> > major surgery.
>
> I don't see any problem with that.

Sure you don't, because you're not the one who'd have to do the
surgery.

                                    -- Adam