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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,63a41ccea0fc803a X-Google-Attributes: gid103376,public From: Brian Rogoff Subject: Re: Naming of Tagged Types and Associated Packages Date: 1998/09/07 Message-ID: #1/1 X-Deja-AN: 388743263 References: <6qfp80$p0u$1@nnrp1.dejanews.com> <35CD0A8E.21D64380@sprintmail.com> <35CEBAAF.B9B82820@sprintmail.com> <35F0CAF2.9B447FD2@sprintmail.com> <35F2AEEA.94D37DFF@sprintmail.com> <35F36963.5C7174E9@sprintmail.com> Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: 905187641 15427 bpr 206.184.139.132 Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-09-07T00:00:00+00:00 List-Id: On Sun, 6 Sep 1998, John G. Volan wrote: > Brian Rogoff wrote: > > On Sun, 6 Sep 1998, John G. Volan wrote: > > > Funny, I'd say its precisely this quality that should make _Type the > > > *first* resort! :-) It's so generally applicable as a type-marking > > > suffix one might as well use it everywhere... > > > > Exactly my line of thinking too :-|. This is one of the reason's I like > > the Dylan convention of delimiting type names with angle brackets; this > > convention has the pleasing (to me) effect of making type names look very > > different from other lexical items. > > I assume this makes it possible to do something like: > > Car : ; > Color : ; > > In other words, the Dylan convention yields what are effectively two > completely disjoint namespaces for object names and type names. The > marking clearly indicates which namespace a given identifier belongs to. > But except for the marking, identifiers in the two namespaces could be > identical. Exactly. Its a convention, the same one as the _Type convention for Ada, except that it is used consistently in the base Dylan language, and I personally find it easier to read than _Type. I'm aware that opinions will differ. > Compare that with the style convention in Eiffel, where all-uppercase > is used for type names and all-lowercase (or mixed case) is used for > entity names. e.g. > > car : CAR > color : COLOR > > In this case, the language really does maintain two dijoint namespaces. > The capitalization scheme is just a convention; Eiffel is actually > case-insensitive, but it uses syntactic context to decide which > namespace to use at any given point. I don't like this, but I imagine if I spend every day for a few days staring at consistently formatted Eiffel code I'd come around. However, I'd also suggest that some amount of type inference in the language would remove some of the burden of name invention, and thats generally a good thing. No comment on your new signature ;-). -- Brian