🚀 go-pugleaf

In article <BEVAN.92Apr10180934@panda.cs.man.ac.uk>, bevan@cs.man.ac.uk (Stephen J Bevan) writes:
|> [...]
|> So why use a definition of `type' that has such a narrow scope.  IMHO
|> `static type' is comonly used to describe what you want, so why not
|> use that?

Why make things so hard on myself?  To talk about `static type'
implies that there's something called `dynamic type' which, as
far as I can tell is indistinguishable from `value'.  But I
already use the word `value' for this concept.  Or, maybe you 
want both `type' and `value' to be further distinguished by
`static' and `dynamic' modifiers - thus making four phrases
to describe two concepts.  Ok.  Is this what everyone wants?
Natural language can be arbitrarily defined like this (at least
for the purpose of discussion).


Having said that, let's get back to the real discussion.  It has
been my regular contention that the _user_ should have explicit
control over which attributes of a variable are static and which
are dynamic.  Some possible attributes are so important and so 
common that they deserve a separate syntax and an exalted position
at the beginning of procedure bodies to `declare' them.  

In J, SmallTalk, etc. _all_ attributes are dynamic and can only be 
restricted by run-time tests (or, what are usually likely to be run-time 
tests anyway - it is possible for the compiler to statically resolve some 
of these if it stretches state-of-the-art compiler technology to the 
utmost - something no J compiler yet does, since there are no J compilers).
Such run-time tests don't improve the legibility or maintainability of
the code at all since they are site-of-use tests, not declarations.

In Fortran, the user is often forced to statically specify something
he wishes to make dynamic.  The Fortran 90 capability of overloading
procerdure names is a weak method of getting around part of this
problem.  A true generic type mechanism would be better.  Actually,
nothing is needed beyond discriminated unions.  If I could say:

      type ANY_RANK = UNION
         real :: x
         real :: y(:)
         ...                      ! the rest must actually be present
         real :: z(:,:,:,:,:,:,:)
      end type ANY_RANK

      type(ANY_RANK) :: A

With this declaration, A could be an array of any legal rank (Fortran 90
is still limited to 7).  You could declare functions of this type, 
function arguments of this type, operators on this type, etc..  

Further convenience could be added:

      type Rank_4_or_more = UNION
         real ::x(:,:,:,:,...)
      end type Rank_4_or_more

Here the `...' simply stands for zero or more unspecified size
additional ranks.  This declaration defines a real array type
with at least 4 ranks (you could even explicitly specify the 
size of the first four explicitly if you want - or you could
declare the base type to be something else - even another union
type).  This gives the use control - everything can be explicitly
static or explicitly dynamic ant the user's option.

As I've consistently stated, the best possible solution is for the
language to supply _both_ capabilities and let the user decide which
to use on each procedure written.

J. Giles