Re: Rational for not making cursor tagged in Containers

[Adam Beneschan <adam@irvine.com>]

On Apr 23, 12:18 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> >>    type GUI_Boolean (Defined : Boolean := True) is (False, True);
>
> >> When Defined = False, the value is rendered as blank and the user is forced
> >> to enter it before it closes the dialog box.
>
> > 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?


> > What does "X = True" mean?  Does X.Defined have any effect on the
> > value of this expression?
>
> > OK, X is a GUI_Boolean that has Defined=false.  You now want to create
> > Y to be a GUI_Boolean that has the same value as X but Defined=true.
>
> This is semantically wrong for GUI_Boolean. An undefined value has no
> defined value...

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".



> > There are lots of syntactic and semantic issues involved with sticking
> > a discriminant on a scalar that you probably haven't thought through.
>
> All these problems were solved for the type String. In general, the
> problems you have referred equally apply to attributes of values. Ada has
> lots of attributes of values, whether scalar or not. That never was a
> problem.

But if you want the ability to put a discriminant on a scalar, the
meaning of the discriminant is *user*-defined, not language defined.
That isn't the case with any of the attributes on String.  Those
attributes are defined by the language.  I believe that the kinds of
discriminants you refer to pose a whole new set of problems that do
*not* apply to the String type.  For example, you need new syntax just
to allow the programmer to write the user-defined "=" functions that
you've referred to.  For another example, when you have an expression
of type String, the String attributes are defined by the language (at
least in most cases), so all the program has to do is give the values
of the character components; but since a discriminant's meaning is
user-defined, the language has to give the user a way to specify the
correct value; 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.

                                          -- Adam