Re: Rational for not making cursor tagged in Containers

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

On 25 Apr 2007 17:58:12 -0700, Adam Beneschan wrote:

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

The predefined equality compares memory bit patterns. Observe, that for any
fundamental built-in type there is no way to define equality otherwise than
this way. An implementation shall ensure that different values of the
discriminants and the positions of values render predefined comparison to
false.

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

Yes, and this is a desired feature. It is important to clearly understand
that discriminant is not yet-another-record-field. Discriminant is a
constraint put on the values. If you have two values of the type and three
values of the constraint, then it shouldn't wonder you that this construct
wouldn't be much usable. What is the difference between Defined_By_Config
True and Defined_By_User True? Just bad design and language misuse.

---------------
My point was, logically and semantically any type may have discriminants =
be dynamically constrained.

It is quite difficult (IMO impossible) to show why some special classes of
types may not be constrained. There exist very strong cases for real,
access and array types which indeed require discriminants. I mentioned them
in other posts. The rest is basically enumeration types and Robert Duff
asked for an example for Boolean type. It was a challenge to think an
example out, I hope you enjoyed it. For a more elaborated enumeration type
I would probably propose dynamically constrained ranges of, or something
similar. But again, that was not the point.

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