Re: Distinguishing type names from other identifiers

[Brian Rogoff <bpr@shell5.ba.best.com>]

On Tue, 27 Jan 1998, Matthew Heaney wrote:
> In article <Pine.BSF.3.96.980127125056.10823A-100000@shell5.ba.best.com>,
> Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> >and I never have collisions between type and variable names. In generic 
> >code, choosing specific names (as Matthew Heaney suggested, I think)
> >becomes much harder, the code is generic after all. This convention also
> >makes it easy to write source analysis tools which get type names by 
> >simple lexical analysis, and, IMO, is easy on the eyes. I agree, it is
> >redundant, but then so are comments, readable names, the distinction in
> >Ada between functions and procedures ;-), ...
> 
> In practice, names for generic types aren't any harder either.  The
> convention I use is something like 
> 
> generic
>    type Stack_Item is private;
>    with function "=" (L, R : Stack_Item) return Boolean is <>;
> package Stacks is 
> 
>    type Root_Stack is abstract tagged null record;
> 
>    function Top (Stack : Root_Stack) return Stack_Item;
> ...
> end Stacks;

That's a very nice convention, but as you acknowledge below, its really no 
different from _Type, since you add a redundant qualifier "Stack_" to the 
name. 

> Here's one case where I'd concede that the _Type convention makes sense,
> because you want to emphasize the inchoate character of the formal type. 
> But I pretty much use the adjective+noun convention for formal types too,
> for consistency.

That seems reasonable to me. I'd have no problem adopting this, even if I
prefer "_Type" ;-). I would also use _Func, _Proc, for access to function 
and procedure, and _Class (for classwide types); I think that's about it.
In Beidler's Scranton data structure suite a far more elaborate naming
scheme is used, but its too much for my tastes. GNAT code is more like
yours, except less verbose, i.e., more abbreviations. I can live with
that, though obviously I prefer the style I'm describing.

> Another example is importing an active iterator as a generic formal type:
> 
> generic
>    Max_Depth : in Positive;
> package Stacks.Bounded is
> 
>    type Bounded_Stack is new Root_Stack with private;
> ...
>    generic
>       type Source_Stack is new Root_Stack with private;
> 
>       type Source_Stack_Iterator (Stack : access Source_Stack'Class) is 
>          new Root_Stack_Iterator with private;
> 
>    procedure Generic_Copy
>       (From : access Source_Stack'Class;
>         To      : in out Bounded_Stack);
> 
> end Stacks.Bounded;

This is also OK, but I still don't see why you find the redundant _Type 
to be "noise" and the redundant _Stack, not-noisy. I find qualifiers like 
_Stack worse, since qualified package names already have that information. 
What's your thinking on this? 

> Boy oh boy, I really, really wish we had access constant parameters and
> discriminants.  Oh well.

Yeah well. I wish hard for out mode function params, but it ain't gonna 
happen. Its really nice to have a language thats not changing all the
time too! When the next Ada 200X thread starts, we'll all have a chance. 


-- Brian