Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!iuvax!uxc.cso.uiuc.edu!deimos.cis.ksu.edu!unmvax!brainerd
From: brainerd@unmvax.unm.edu (Walt Brainerd)
Newsgroups: comp.lang.fortran
Subject: Re: dpANS Fortran 8x
Summary: Some reasons against this kind of typing.
Message-ID: <201@unmvax.unm.edu>
Date: 6 Jul 89 00:59:38 GMT
References: <2724@elxsi.UUCP> <6105@microsoft.UUCP> <193@unmvax.unm.edu> <6234@microsoft.UUCP>
Distribution: usa
Organization: University of New Mexico at Albuquerque
Lines: 47

In article <6234@microsoft.UUCP>, bobal@microsoft.UUCP (Bob Allison) writes:
> >statement has to do with anything, either.  What I think is being requested
> >is the ability to do something like this (all statements begin with
> >a keyword):
> >
> >TYPE LONGEST_INT 
> >INTEGER(64)  ! with or without a paramter
> >END TYPE LONGEST_INT
> >
> >and then be able to declare
> >   
> >TYPE (LONGEST_INT) :: entity-decl-list
> >
> >Walt Brainerd  Unicomp, Inc.  brainerd@unmvax.cs.unm.edu
> 
> Well, I thought the discussion was about how user-defined types should be
> able to be declared just like intrinsic types are, so that your last line
> would be:
> 
>        LONGEST_INT [[attribute-list] ::] entity-decl-list

Yes, I agree there would be syntactic problems with this form.

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.
-- 
Walt Brainerd  Unicomp, Inc.  brainerd@unmvax.cs.unm.edu