mouli@cavell.UUCP (Bopsi ChandraMouli) (11/01/84)
Recently I started reading about Ada and I was surprised
to a great extent that Modula-2 outshines Ada with respect
to interface specification of program units.
Things in Ada that I feel, are inferior to Modula-2 are:
1) You can not have anything else in the specification
part other than the ones you are exporting.
This can result in cumbersome specification.
2) Packages can not selectively IMPORT objects from other packages.
It is either ALL or NONE situation. This will have severe
impact on the readability of the source code.
I feel that Modula-2's SELECTIVE import and export mechanisms
contribute to better PROGRAM READABILITY AND SCOPE
CONTROL than Ada's import and export mechanisms.
3) For private and Limited private types you have to give
the full representation of the types in the specification part itself.
This is really annoying. Even at the specification stage
you are forced to take a decision on the representation which
may not always be possible. Also, it is a good idea to
hide the representation in addition to making it inaccessible outside
the package. The specification part usually serves as
a good documentation feature and why give other programmers some
details which are totally unnecessary.
I am curious to know what others feel about these views.
Is there any good reason behind the design of such (Ada's)
interface specification mechanisms?
Bopsi Chandramouli
U. of. Alberta.colbert@spp1.UUCP (11/15/84)
> > Recently I started reading about Ada and I was surprised > to a great extent that Modula-2 outshines Ada with respect > to interface specification of program units. > > Things in Ada that I feel, are inferior to Modula-2 are: > > 1) You can not have anything else in the specification > part other than the ones you are exporting. > This can result in cumbersome specification. I assume you are referring to a Package Specification. If so the your perspective is backwards. Its not that "You can not have anything else in the specification part....", its that anything you put in the Visible part of a package specification is exported. If you need something in your specification that you don't want to export then put it in the private part of the Package Specification (You can put anything you want in the Private part of a Package Specification). If this solution is not satisfactory then you probably should evaluate whether you should have furthur modularization of some part of your package into 2 or more packges. > 2) Packages can not selectively IMPORT objects from other packages. > It is either ALL or NONE situation. This will have severe > impact on the readability of the source code. > > I feel that Modula-2's SELECTIVE import and export mechanisms > contribute to better PROGRAM READABILITY AND SCOPE > CONTROL than Ada's import and export mechanisms. > This can be accomplished in Ada by creating a package containing renames of those items that you wish to import. For example the following is a Simple I/O package that I provide to my class when they are first starting out so that they can write programs that have I/O (useful capability) without needing to know the gory details of Text_IO. with text_io; use text_io; package simple_io is package int_io is new integer_io (integer); use int_io; procedure put (c: character) renames put; procedure put (i: integer; width: in field:= default_width; base: in number_base := default_base) renames int_io.put; procedure put (s: string) renames put; procedure put_line (s: string) renames put_line; procedure get (c: out character) renames get; procedure get (i: out integer; width: in field := 0) renames int_io.get; procedure get (s: out string) renames get; procedure new_line (spacing: in positive_count := 1) renames new_line; data_error: exception renames text_io.data_error; end_error: exception renames text_io.end_error; end simple_io; A program that only wants to do this Simple I/O only needs to import this package. > 3) For private and Limited private types you have to give > the full representation of the types in the specification part itself. > This is really annoying. Even at the specification stage > you are forced to take a decision on the representation which > may not always be possible. Also, it is a good idea to > hide the representation in addition to making it inaccessible outside > the package. The specification part usually serves as > a good documentation feature and why give other programmers some > details which are totally unnecessary. > The full representation of a private or limited private type in the PRIVATE PART of a package is information required by a Ada compiler to fully support separate compilation. Ada allows a compilation to import a package or subprogram from the library whose declaration has been compiled but whose body has not been compiled (maybe not even written). In order to generate the proper code for a call to a subprogram thats a library unit or thats part of a package thats a library unit, the compiler needs to know the for representation of the private or limited private type. While a user can read the PRIVATE PART and see how the private or limited private type is implemented, the rules of Ada prevent him from making use of that knowledge in his program (at least in theory. A user may make assumption about the processing based on what he has read). If you need/want to hide totally the defintion of the private/limited type from the eyes of a user of that package, Ada provides a means. To accomplish this you must use incomplete & access types. Ada says that the full type declaration of an incomplete type that is declared in the private part of a package can be deferred to the body of the package. Therefore you can do the following: package demo is type private_type is private; . . . private type my_hidden_type; type private_type is access my_hidden_type; end; package body demo is type my_hidden_type is ....; -- full declaration end; While I have used or read Modula from what I've heard both Ada and Modula have individual features that are better than the others, but I haven't heard of anything that made one of them overwhelmingly supperior to the other. Ed Colbert Ada Technology Group TRW