RE: [vhdl-200x-ft] Question on Type and Package Generics

Tristan,

Sorry for the delay in responding to this - it collided with Christmas and
then got buried in my inbox.

> > However, we decided
> > to limit formal generic types in the current revision to be
> > essentially like Ada "is private" generic types.
> I have one comment.
> Unless I miss some point, there is no formal subprogram in
> the generic list. I really think this is a mistake. Generic
> will not be powerful enough to create a generic sort
> subprogram! Furthermore, the analyzer need to make checks
> during the analysis of a generic package/subprogram.

The proposal does provide for formal generic subprograms, along the same
lines as in Ada.

> > The main reason for doing so is that we
> > plan to develop object-oriented extensions to the type system in a
> > later revision. Whatever we do with generic types needs to be
> > compatible with the extensions to the type system. I've proposed a
> > minimal form of generic types that I believe will not constrain the
> > type-system extensions.
> I don't follow. Generics and type extension are really
> orthogonal features.

But there is interaction. Specifically, I've suggested that OO types be
provided by extending protected types into class definitions, since
protected types already provide many of the needed features. What's mainly
missing is derivation and dynamic dispatch. I've also suggested that the
existing type constructors of VHDL could be expressed as a class hierarchy
using class definitions. The existing syntax for type definitions and
operations could then be re-specified as syntactic sugar for the new class
and their operations. Subtype relationships could be expressed in terms of
subclassing.

The interaction with generics is that you want to be able to specify a class
of type for the formal, apply only those operations that are approriate for
the formal type, and constrain the actual to be a subclass. You'd want to
provide generic types that allowed for this with user-defined class
hierarchies. Having done that, you would also get the same features working
for the predefined class hierarchy representing the existing type classes.

Now we could assume that, if we provided type information for formal types
in the same way as in Ada, it could be treated as syntactic sugar for
class-based formal type definitions. However, since the details of the OO
approach are yet to be worked out, making that assumption is a risk. It may
back us into a language design corner that we'd regret when doing the OO
language design. Moreover, it would represent significant effort that would
be discarded when subsumed by an OO approach.

For these reasons, I'd prefer to treat type generics and OO as mostly
orthogonal but interacting, and defer designing a more elaborate mechanism
for type generics to a later revision.

> > Ada-95 introduced object orientation through extensions to packages
> > and to types and operations defined in packages.
> I don't agree on the last point: extensions to packages (aka
> child packages) is not object orientation.

I was not referring to child packages. (I apologize if I've abused
terminology.) Rather, in Ada-95, the extensions are by declaring a package
that derives a new type from a parent type in another package. The deriving
package can add further primitive operations to those defined in the
original package. In this sense, the type and operations in the second
package extend those of the first package.

> > While we could do similarly, we
> > need to recognize the VHDL's protected types are closely aligned to
> > class definitions in OO languages.
> Again, I don't really see the point. Is there any reference
> ? Protected types are not OO. No polymorphism, no type extensions.

Agreed, they are not all that is required. However, they do provide for
encapsulation and hiding of state, and access to that state using publicly
visible methods. They look very much like class definitions in many OO
languages. I think it would be cleaner to extend protected types and keep
packages as simple scope fences. If we were to adopt the Ada-95 features
for OO, would would end up with much semantic overlap between sets of
language features. That would make the language harder to use, since users
would often be unclear about which feature set to use, and may make choices
that constrain evolution of their designs.

> > There is a preference among WG members to
> > develop OO features based on extending protected types
> rather than by
> > following the Ada-95 approach. Either way, this will take
> some effort
> > to develop, hence it's deferred to the next revision.
> (Which, by the
> > way, need not be as far away as 5 years from the current rev)
> >
> > I hope this clarifies the direction being proposed.
> Sure, it does. Again thank you for the historical view.
> However, I really think the generics as currently proposed
> are not powerful enough to be useful.

I agree that their usability is limited, but with the intent of being
expanded signficantly in a subsequent revision of the language.

Cheers,

PA

--
Dr. Peter J. Ashenden                        peter@ashenden.com.au
Ashenden Designs Pty. Ltd.                   www.ashenden.com.au
PO Box 640                                   Ph:  +61 8 8339 7532
Stirling, SA 5152                            Fax: +61 8 8339 2616
Australia                                    Mobile: +61 414 70 9106