Re: Rational for not making cursor tagged in Containers

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 23 Apr 2007 17:15:06 -0700, Adam Beneschan wrote:

> 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?

Yup, the predefined "=" should be renamed first.

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

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

For unconstrained enumeration types (no default value for a discriminant),
literals should be generated abstract [primitive operations], to be
overridden if the type is not abstract.

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

I don't see any problem with that. The values of scalar types are
constructed using literals and operations defined on them. The predefined
equality (if any) involves the discriminant value.

If the user is unable to implement equality, then it is not because there
should be no discriminants. It is because the user has chosen a wrong type.
And it is an extremely useful language feature not to let him to compare
incomparable things.

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