One way to achieve at least the semantics (but I do not know whether
the Fortran standard allows that), is not to use integer parameters,
but derived type parameters:

type Enum1
   integer intv
end type Enum1

type(Enum1), parameter :: E_1 = Enum1( 1 )

or something to that effect

Regards,

   Color_var := red;

If you try to assign it a value of any other type, the compiler
issues a message (or should).  Hence the following are illegal:

   Color_var = 7;
   Color_var = 'red';
   Color_var = tree; {tree is an enumeration value of a different type}

Etc..

In C, if you declare an enumerated type, it is really just an alias type
for some (implementation chosen) int type.  It provides no real type
safety at all.  So, if you declared Color again in C,  and declared
a Color variable, the following would be legal:

   Color_var = red; /* this is the one that Pascal accepted */
   Color_var = 7;
   Color_var = 'r'; /* type char is integral in C */
   Color_var = tree; /* a different enumeration type is also integral */
and even
   Color_var = "red"; /* address of the array is stored in Color_var */

Since these are all legal, the compiler can't issue error messages for
them.  I doubt that any C compilers even warn that these might be
unintended.

In Fortran you can emulate either behavior.  If you want the Pascal
rules, you must define your own derived type with an integer field
and declare your constants of that type.  Each with a separate value.
You can then assign only those constants, other variables of that
type, or explicitly cast integers to that type (at least it's explicit).
You could overload an assignment operator for the type to guarantee
that explicitly cast integers were at least among the set of allowed
values.

If you want the C rules, you just declare a bunch of names integer
constants for the literals of your new "type", and declare the variables
to be of the appropriate integer KIND.   Now, just about everything
is legal again (though the cast from CHARACTER must be explicit and
you can't assign an array's address to an integer in Fortran).  Of course,
you really don't have any type protection.

Fortran 200x contains a proposal for directly implementing the C style
of enumerations. :-(  This is not only unnecessary (since we can already
emulate the C stuff), but it effectively eliminates the possibility that a
better form of ennumerations will ever be considered.

type
  Colors = (Red, Blue, Green, Yellow)
var
  SweaterColor : Colors

then in the code:
  SweaterColor := Blue     { OK }
  SweaterColor := 14        { compiler error }

How would you emulate this in Fortran?  It's the compiler error I'm particularly interested in emulating.

Type Colors
   Integer :: val
End Type Colors

Type(Colors), Parameter :: Red = Colors(0), Blue = Colors(1), &
                          Green = Colors(2), Yellow = Colors(3)

Type(Colors) :: SweaterColor

...

   SweaterColor = Blue   ! OK
   SweaterColor = 1     !  Same number even, but still illegal.
   SweaterColor = Colors(14)  ! Unfortunately legal.

To catch the last one, you would have to define your own assignment
operator for the Colors type.  You could then check that the value
assigned was within the set of defined colors.

Modulo the Usual Caveats (Hi Richard!), enumerations were
added to F2K as part of the C Interoperability stuff.
I.e., it works like C because it's made to work like C.
And it was made to work like C because it was added
in response to comments from those coding Fortran - C
interfaces regarding the at-the-time Interoperability stuff,
IIRC.

Nobody's asking for the Pascal Interoperability chapter :-(
Now that we have Delphi for Linux, maybe there's hope :-)

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

On Wed, 14 Nov 2001 19:14:40 GMT, "James Giles"

Adrian

You can't -- but I've learned long time ago (on my own mistakes :-()
that one should *never* use literals in the code wherever they
mean something special. I sympathize with you, but I'm afraid
that the only cure is to impose self-discipline :-). I'm ready
to kill my co-workers when I find in their code:

iNodeType = 2

even if there is a set of parameters defined in a header file:

INTEGER, PARAMETER::  NT_ROOT = 1
INTEGER, PARAMETER::  NT_JOINT = 2...

! define types
  Type Colors  ; Integer(1) :: val ; End Type Colors
  Type Numbers ; Integer(1) :: val ; End Type Numbers

! define enumerated type values
  Type(Colors ), Parameter :: Red  = Colors (0), Blue = Colors (1), Green = Colors (2), Yellow = Colors (3)
  Type(Numbers), Parameter :: Zero = Numbers(0), One  = Numbers(1), Two   = Numbers(2), Three  = Numbers(3)

! define variables
  Type(Colors) :: SweaterColor

! code
  SweaterColor = Blue    ! OK
  SweaterColor = 1       ! Same number even, but compile error
  SweaterColor = One     ! Same number even, but compile error   <----- this is the error I'm really interested in trapping

Yup, really cool. Wow, what speed -- is this ICQ or usenet? :-)

The program I wrote (see the end) produces these errors:

f90 -o adrian adrian.f90

   var1 = w1
        ^    
"adrian.f90", Line = 22, Column = 9: ERROR: Assignment of a type(ENUM2)
expression to a type(ENUM1) variable is not allowed.

   var2 = v1
        ^    
"adrian.f90", Line = 23, Column = 9: ERROR: Assignment of a type(ENUM1)
expression to a type(ENUM2) variable is not allowed.

f90: COMPILE TIME 0.080000 SECONDS
f90: MAXIMUM FIELD LENGTH 1785642 DECIMAL WORDS
f90: 28 SOURCE LINES
f90: 2 ERRORS, 0 WARNINGS, 0 OTHER MESSAGES, 0 ANSI
f90: CODE: 0 WORDS, DATA: 0 WORDS

Quite what you want.

Here is the source code:

program enums
   type enum1
      integer :: value
   end type enum1
   type enum2
      integer :: value
   end type enum2

   type(enum1), parameter :: v1 = enum1(1)
   type(enum1), parameter :: v2 = enum1(2)
   type(enum2), parameter :: w1 = enum2(1)
   type(enum2), parameter :: w2 = enum2(2)

   type(enum1) :: var1
   type(enum2) :: var2

   var1 = v1
   var2 = w1

   write(*,*) var1, var2

   var1 = w1
   var2 = v1

   write(*,*) var1, var2

   stop
end program

(So, perhaps F90 is not all together that bad! You can emulate the
Pascal conventions already!)

Regards,

But have in mind that both codes ("C flavor" or "Pascal flavor")
as well as James's sample with Fortran derived types would (probably)
result in identical machine code. (Provided derived type containing
an integer(4) is still 4 bytes long).
It's only the compile-time that matters, so "Pascal flavor" enums should
serve equally well for C interoperability.

I'm not positive about the statement above -- would someone please correct
me if I'm wrong?

This does raise a question though:
Can such enums be cast into an ordinary data type, as with C? Surely
the Pascal flavour should disallow that and the C flavour should
be quite happy with such an operation.

My conclusion is that as long as Fortran may "know" about the C types,
the C flavour is quite unnecessary. Only the Pascal flavour adds
anything,
and it has been demonstrated that can be done with Fortran 90 (even
though
it is more verbose than Pascal).

Regards,

I generally agree that, in many ways, the Pascal flavor
would be superior.  I agree that enums can be done
in f90 in an acceptable way.

IIRC (and the brain cells may be getting rusty), enums
were added to f2k in response to requests from folks
who were reading the C Interoperability stuff, and actually
trying to see how it would be used on current projects, and asked
for enums which would map simply into C enums.  That means:

the same rules in f2k and C for choosing which integer to use
(which means that, legally, the f2k compiler is obliged
to use whatever the companion C processor is using, and
that, in practice, default integers usually will be chosen)
and
the same (lax) rules for setting enum values
and
the same lack of connection between enums and select case/switch

The goal was to be able to write a Fortran module to,
e.g., interface with a C graphics library, allowing use
of the "same" enums on both sides (the pedantic
example being color).  I believe j3 has
honored that request reasonably well.

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

On Thu, 15 Nov 2001 16:50:39 +0100, Arjen Markus

The standard doesn't include such an automated translator, but I think
parts were designed to facilitate them.

(Not that I'm a great personal fan of our current enum implementation
as being a hugely important feature; I wouldn't weep if for some
reason, if enums just got dropped.  Nor was I about to go out and
crusade for dropping them, though.)

which he fixed with overloading the .eq. operator:
  interface operator(.eq.)
    module procedure porky
  end interface
...
    logical function porky(a,b)
      type(colors), intent(in) :: a,b
      porky = a%val.eq.b%val
    end function porky

However, SELECT CASE does not work.  Is it possible to override this operator?

Yes, you must extend == (absolutely synonymous with .eq.)
to make it applicable to any derived type.

There is no operator in the select case block,
so I don't see how to extend it.  One cannot extent
where, do, if or any other block structure, either.

What you've done is write a procedure which accepts
two type colors and returns a scalar default logical
expression.  That fits into the if.

Perhaps you could use

select case( sweatercolor% val)
case( red% val)
etc.

to achieve your desired result.

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

On Thu, 15 Nov 2001 14:08:31 -0600, "Adrian Ferramosca"

The emulation of enumerations with derived types allows all the
flexibility of internal values that C does.  But, I could find nothing
in the Fortran standard that requires an array of such derived
types to be the same internal storage as an array of the underlying
member type!    That would be the only hole in the use of derived
types as the mechanism for providing enums in Fortran and still
having them interoperate.  (I thought of this last year when I wrote
an article on this subject, but couldn't resolve it.)

Dan Nagle points out that one advantage of including enums
directly into Fortran in the C form is that the compiler will then
automatically select the KIND of integer that corresponds to
the int type that the companion C compiler would choose for
the same set of values.  This is only sort of true.  The C standard
doesn't require implementations to choose the int type that they
use for unums in any sensible way.  It can vary from one
implementation to another, or even from one revision to
another within the same compiler (though, I guess even
C programmers demand some kind of backward compatibility).
And if you needed to interface with more than one vendor's C,
you really don't want to have to buy Fortran from both ventors
do you?  So, to be really safe you'd really have to do your own
due dilligence and make sure that you were really using the
correct KIND.

In any case, the question of whether the KIND is selected
automatically to match some C implementation is independent
of the other aspects of a Fortran implementation.  You could
implement the Fortran feature as genuinely type-safe and still
pick the appropriate KIND for C interoperability.

Richard Maine says that the C flavor of the feature was selected
not just to facilitate interoperability, but to allow automatic
translations of C headers and other code into Fortran.  While
this may seem a useful goal, it is not really necessary.  If the
C code says SweaterColor = 1 and the naive translation of
that causes the Fortran compiler to complain: so that the
programmer has to recode it into SweaterColor = Colors(1),
that's not really a severe inconvenience.  And it may even
result in the isolation of a latent bug in the C code!

--

Sorry for responding to three articles in one message.  But
I really didn't want to fragment the thread to that extent.

For current purposes, only integers are interesting, so it looks like
we are limited to default integer components.  That is a bit
restrictive.  (Though I seem to recall that though other possibilities
are allowed in principle, current C compilers tend to always use
32-bit integers for all enums unless you go out of your way to specify
otherwise.  I could misrecall that.)  Anyway, as long as you have only
default integer (or some other things not interesting here) components
and declare the type to be sequence, then you are ok.  In that case,
the type is required to be equivalencable (no that's not the word the
standard uses - indeed it's probably not a word at all, but I'll use
it anyway) with corresponding sequences of default integers, which is
the guarantee you were looking for.  Only for limited cases, true, but
it is guaranteed for those cases (and it at least includes some useful
cases, though it omits others).

Hmm. I see that 14.6.3.1 (Storage sequence) sort of makes it sound like
you would be ok for any sequence type.  Namely

  (7) A nonpointer scalar object of sequence type occupies a sequence of
      storage sequences [odd phrasing, that, but I guess it is right]
      corresponding to the sequence of its ultimate components.

Hmm.  But you aren't allowed to do the "obvious" equivalence/common
things, unless the type is a numeric (or character) sequence type, so
perhaps the above quote doesn't say quite what it looks like to me at
the moment.

On Thu, 15 Nov 2001 20:57:59 GMT, "James Giles"

IIRC, there's even a note in the current draft saying that
there may be more than one ISO_C module, of course, it's
beyond the standard to say how the choice is made (what the
switch is called/how it's selected/etc.).

<snip>

--
Cheers!