Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!psuvm.bitnet!psuvmxa!cunyvm!byuvax!hallidayd
From: hallidayd@yvax.byu.edu
Newsgroups: comp.lang.fortran
Subject: Re: dpANS Fortran 8x
Message-ID: <685hallidayd@yvax.byu.edu>
Date: 8 Jul 89 06:34:06 GMT
Lines: 83

Walt Brainerd (brainerd@unmvax.unm.edu) in message <201@unmvax.unm.edu> writes
>In article <6234@microsoft.UUCP>, bobal@microsoft.UUCP (Bob Allison) writes:
>> ...
>>        LONGEST_INT [[attribute-list] ::] entity-decl-list
>
>Yes, I agree there would be syntactic problems with this form.

I would like to see
        intrinsic_type [[attribute-list] ::] entity-decl-list
and
        user_type [attribute-list] :: entity-decl-list
Thus eliminating the need for the TYPE(user_type_name) construct, while not
having the syntactic problems inherent in using user defined types in old
FORTRAN declaration statements.  (A point I have made in several other
postings to this news group.)


>
>Lawrie Schoenfelder (X3J3 member from Liverpool) has given some of his
>reasons why he would not like to have the sort of typing I illustrated
>above.  I think they are valid.  Basically, they are that operations
>on new types should not be inherited from the components.  In the example
>above, that's exactly what you want to do (have +. *, etc. available
>for the new LONGEST_INT type).  But what if the new types are physics
>quantities like mass, time, etc. that are real numbers, but shouldn't
>be arbitrarily multiplied by any old real numbers?  With the currently
>proposed scheme, the only inherited operations are assignment and
>component selection because each type must be a structure and those
>are the only intrinsic operations on structures.  You can still
>do something like MASS % VALUE * TIME % VALUE to multiply strange
>things together, but the "%VALUE" does give some indication that
>something strange is going on.  Also, Lawrie rightly believes that most
>of the production of new types should go on inside modules; here it
>possible to make access to components private, even to a program
>that used the type definition, so this forces the programmer using
>the new type to do all computations with the new type via the operations
>provided for values of that type in the module.
>
>Now I'm not sure what I think of all this.
>More opinions would be interesting.

I most certainly agree.  We, as programmers, should have the ability to
appropriately restrict the operations allowed on new data types that are
defined, at least those defined within MODULES.  The concepts of
abstraction and information hiding are long overdue in Fortran.  With the
ability to abstract and hide information (data structures, types, etc.) we
have the ability to provide specialized packages to accomplish specialized
tasks, where the ability is retained to update, and completely change, the
algorithms and data structures as the need arises, without breaking users
code.  I have no problem with the restriction this has placed on the
definition of data types in the proposed Fortran standard, though this need
does not *require* that user defined types be structures and subject to the
accompanying restrictions (see the way Ada has such restrictions on PRIVATE
types, but not on types that are made public).

Along with the ability to _hide_ information, we must also be able to
provide the operations the user desires in the most transparent way
possible (or the user will object to having the information hidden from
his/her view).  This is where operator overloading comes in---the ability
to define, for instance, a division operator for the cases where such an
operation is appropriate (such as dividing a distance type by a time type
to yield a velocity type).   Furthermore, in order to make such information
hiding and abstraction truly useful, we must have the ability to define new
sets of types and operations (within a MODULE, usually) which can make use
of the types and operations previously defined (usually within another
MODULE), without the necessity of having the source code (thus violating
information hiding).

The ability to have parameterized types does, however, seems to be an
appropriate way to have multiple types that share operations (including the
ability to pass objects of all such types as arguments to the same
procedure, eliminating the need for several copies of the procedure)---in
fact, parameterized types provide, IMHO, a clearer indication of the
relationship between types that share operations (thus, again, the need for
user defined types to be able to have parameters, and perhaps, even
defaults for these parameters, so the relationships between user defined
types may be just as apparent as for the intrinsic types).

   _____________________________________
  / David Halliday                      \
  |                                     |
  | Internet:    hallidayd@yvax.byu.edu |
  | BITNET:      hallidayd@byuvax       |
  | Us Mail:     BYU Physics Department |
  |              296 ESC                |
  |              Provo, UT  84602       |
  \_____________________________________/