From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,1a52c822fc0dbb23 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!q75g2000hsh.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Rational for not making cursor tagged in Containers Date: 23 Apr 2007 17:15:06 -0700 Organization: http://groups.google.com Message-ID: <1177373706.552914.71270@q75g2000hsh.googlegroups.com> References: <1176998738.656903.141250@q75g2000hsh.googlegroups.com> <1177010938.200523.325290@p77g2000hsh.googlegroups.com> <1a8y2vakorfhx.225uqh4hifpd$.dlg@40tude.net> <1xmzi7newnilp.23m3zze8h9yi.dlg@40tude.net> <1177066583.5876.30.camel@localhost.localdomain> <1177080147.5876.87.camel@localhost.localdomain> <1q1kx2jlcvnuj.ck0711mj4few$.dlg@40tude.net> <1177097829.26685.36.camel@localhost.localdomain> <95wmj9goo6wc$.13f1j4dnadwws$.dlg@40tude.net> <1177349886.343834.295210@q75g2000hsh.googlegroups.com> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1177373706 26844 127.0.0.1 (24 Apr 2007 00:15:06 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 24 Apr 2007 00:15:06 +0000 (UTC) In-Reply-To: User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.7.12-1.3.1,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: q75g2000hsh.googlegroups.com; posting-host=66.126.103.122; posting-account=cw1zeQwAAABOY2vF_g6V_9cdsyY_wV9w Xref: g2news1.google.com comp.lang.ada:15246 Date: 2007-04-23T17:15:06-07:00 List-Id: On Apr 23, 12:18 pm, "Dmitry A. Kazakov" 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