enums in Fortran
Adrian Ferramosca
integers, and then use those parameters at runtime, however the functionality I'm really looking for is the restriction that a
variable of enum type has to only specific enums, ie. where one would get a compile time error when an enum variable was set equal
to another enum value not part of the former's definition, even though they may both just be integers.
Adrian
Arjen Markus
As far as I know, this is not a widely supported C functionality. Most
C compilers that I know do not even warn about a potential misuse of
enums.
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,
Arjen
James Giles
Pascal and C have very different rules. In Pascal, if you declare
an enumerated type, say Color, and a variable of that type, you
can only assign values of that type to the variable:
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.
--
J. Giles
Adrian Ferramosca
> > in Fortran? I know it is easy to assign parameters to specific
> > integers, and then use those parameters at runtime, however the
> > functionality I'm really looking for is the restriction that a
> > variable of enum type has to only specific enums, ie. where
> > one would get a compile time error when an enum variable was set equal
> > to another enum value not part of the former's definition, even
> > though they may both just be integers.
>
> Pascal and C have very different rules. In Pascal, if you declare
> an enumerated type, say Color, and a variable of that type, you
> can only assign values of that type to the variable:
>
> 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}
I'm sorry, this is the behavior I meant.
> 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.
ie. similar to Arjen's reply. I'm still unsure how to structure the code such the compiler catches incorrect assignments, and how
to define the enum to start off with. In Pascal I would have:
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.
> 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.
Poor choice. Long live Pascal.
James Giles
"Adrian Ferramosca" <adr...@bjahouston.com> wrote in message
news:HUzI7.2665$Oh1.31395@insync...
...
> 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.
--
J. Giles
Adrian Ferramosca
> 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.
>
Excellent ! Just what I need. I'm not that worried about the Colors(14) problem.
Thanks,
Adrian
Dan Nagle
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"
<james...@worldnet.att.net> wrote:
<snip discussion>
Adrian Ferramosca
extra stuff?
Adrian
"Adrian Ferramosca" <adr...@bjahouston.com> wrote in message news:8kAI7.2667$Oh1.31171@insync...
James Giles
"Dan Nagle" <dna...@erols.com> wrote in message
news:bak5vtcgp83h2u5gg...@4ax.com...
> Hello,
>
> 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 :-)
You missed my point: It's not *necessary* for C interoperability.
As soon as we have integer KINDs corresponding to the C int
types, we will be able to interoperate with C enums *without*
any such feature in Fortran. We should consider enumerations,
if at all, on the merits of the feature in Fortran. It should not
be primarily important as an interoperability tool - no matter
what the other language is.
--
J. Giles
James Giles
"Adrian Ferramosca" <adr...@bjahouston.com> wrote:
> Incidentally, what is the size of the SweaterColor variable? Is it
> just the size of the integer, or does the TYPE tack on a bit of
> extra stuff?
This is almost certainly implementation dependent. But the size
need not be any different from a normal integer (of whatever KIND
you use - my example use default integers).
--
J. Giles
Jugoslav Dujic
| 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.
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...
Jugoslav
________________________
www.geocities.com/jdujic
Adrian Ferramosca
> | 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.
>
> You can't --
Not so, take a look at James's extremely elegant solution, repeated here for conciseness:
! 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
Adrian
Jugoslav Dujic
| > | 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.
| >
| > You can't --
|
| Not so, take a look at James's extremely elegant solution, repeated here for
conciseness:
Yup, really cool. Wow, what speed -- is this ICQ or usenet? :-)
Regards
Jugoslav
Arjen Markus
>
> How would you emulate this in Fortran? It's the compiler error I'm particularly interested in emulating.
>
> > 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.
>
> Poor choice. Long live Pascal.
I agree with the statement "poor choice". I do not know Pascal well
enough
to go for the second part as well. But:
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,
Arjen
Colin Watters
Hear hear. *I* want F2K to include enums that look and work like
Pascal's, not because I want to interoperate with Pascal, but because
Pascal's enums are self-eviently (IMHO) a superior programming
constuct that will greatly enhance the Fortran language. That said I
don't want to prevent C interopability... maybe f2k could have 2
flavours of enums? And call them C and Pascal flavour, in open
acknowledgement of their origins ??
Qolin
Jugoslav Dujic
news:f58d8f0a.01111...@posting.google.com...
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?
Jugoslav
________________________
www.geocities.com/jdujic
Arjen Markus
The Pascal flavour will catch errors that the C flavour will happily
ignore. When the compiler (!) accepts the program code, it can translate
the enum values to anything that is suitable, probably default integer
values. Then neither the linker nor the run-time environment will be
able to distinguish them - nor should they be able to.
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,
Arjen
Dan Nagle
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
<Arjen....@wldelft.nl> wrote:
<snip discussion>
Richard Maine
> 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...
I think it was a bit stronger than that. I recall a lot of
attention to facilitating automatic translation of header files,
so that the Fortran user wouldn't even have to write out the
enum definition - he'd just use the auto-translated one. This
is of interest for large things like X or Windows API interfaces.
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.)
--
Richard Maine | Good judgment comes from experience;
email: my last name at host.domain | experience comes from bad judgment.
host: altair, domain: dfrc.nasa.gov | -- Mark Twain
Adrian Ferramosca
> 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.
>
if (SweaterColor .eq. Blue) then ! does not compile
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?
Adrian
Dan Nagle
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.
James Giles
"Jugoslav Dujic" <jdu...@yahoo.com> wrote in message
news:9t0mk0$15h3nb$1...@ID-106075.news.dfncis.de...
...
> 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?
There are some important differences. The Pascal feature does
not permit the programmer to select what internal value represents
each enumeration constant. This may be important for interoperability
since both C and Ada permit the programmer to override the default
choices there. Further, C permits the enumeration constants to
contain duplicates (ie. two constants to have the same internal
value).
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.
--
J. Giles
Richard Maine
> 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!
I think you are safe here if you use a numeric sequence type.
For the definition of a numeric sequence type, see....darn...
where is that buried?...I found the references to it, but not
the definition...perhaps the index?...wow, there's actually an
entry...thought I skimmed that page before...oh, there it is...
in 4.4.1 of f95, right after note 4.17.
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.
Dan Nagle
On Thu, 15 Nov 2001 20:57:59 GMT, "James Giles"
<james...@worldnet.att.net> wrote:
<snip>
>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.
I think the expectation is that there will be a compiler switch
which selects the companion C compiler. So that, e.g., Lahey
will have a switch which says "C means MSVC" or "C means Borland"
(in addition to "C means Fujitsu").
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>
James Giles
......
> >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.
>
> I think the expectation is that there will be a compiler switch
> which selects the companion C compiler. So that, e.g., Lahey
> will have a switch which says "C means MSVC" or "C means Borland"
> (in addition to "C means Fujitsu").
>
> 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.).
In other words, it's probably safer to still do the due dilligence
to set the KIND directly rather than trust the BIND C, and probably
not much harder either. Especially if you need to interface with
more than one C version from the same executable (like: you
use the Fujitsu stuff for your own C code, but you also have
to interface with the system and that's MS).
--
J. Giles
Jan Vorbrueggen
> 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.
Isn't that only because mixing numeric and character variables in COMMON isn't
standard-conforming in any case, and for EQUIVALENCE purposes, the compiler
doesn't have to support mixing numeric and character data here as well?
The rationale behind this is, I suppose, that numeric values and character
values could have different alignment requirements (e.g., a character could
need to be aligned to 8-byte boundaries while numeric data would be naturally
aligned) so that any such overlaying could not reasonably be made to be
portable.
Jan
Jan Vorbrueggen
> 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).
We have seen exactly this problem, which rears its ugly head when you use such
data types for interchange (e.g., via CORBA). One compiler always allocated 32
bits; the other used 8, 16, or 32 bits depending on the maximum value. So the
enums got an additional value "MAX = 65536" to force the larger allocation...
This is really the point where the use of enums usually breaks down,
unfortunately. It is also the point where things break with X11 or
OS interfaces, which is the same problem in another guise.
Jan
Colin Watters
"Arjen Markus" <Arjen....@wldelft.nl> wrote in message
news:3BF3E44F...@wldelft.nl...
<snip>
>
> 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).
Yes it can be done, but yes it is more verbose, MUCH more verbose. I have
implemented it in my code, and it requires 22 statements to declare the
enumeration type, its parameters, the controlling variable, and the overload
functions necessary to allow equality and non-equality checks. All this to
do what Pascal allows in one statement!
And even then it will only allow comparisons in IF statements, you cannot
use a SELECT CASE unless you allow the enumeration type to be public, which
defeats the purpose because it allows comparison against integer constants.
Here's my implementation, maybe someone can spot something I'm missing...
(sorry if the indentation etc is wrong, I'm posting this from a different
news reader than usual):
!DEC$ FIXEDFORMLINESIZE: 132
module fmdc
c-----type definition for enumerated identifier
type fmdc_enum_type ; integer(1) :: v; end type
type (fmdc_enum_type), parameter :: reciprocating =
fmdc_enum_type(0), centrifugal = fmdc_enum_type(1)
c-----type definition for a generic compressor curve
type(fmdc_enum_type) fmdc_type ! curve type: 'centrifugal'
or 'reciprocating'
c-----overload the .eq. operator to allow sensable testing of curve%cype
interface operator(.eq.)
module procedure porky
end interface
interface operator(.ne.)
module procedure pinky
end interface
private :: porky, pinky
contains
logical function porky(a,b)
type(fmdc_enum_type), intent(in) :: a,b
porky = a%v.eq.b%v
end function porky
logical function pinky(a,b)
type(fmdc_enum_type), intent(in) :: a,b
pinky = a%v.ne.b%v
end function pinky
end module fmdc
Qolin
Jan Vorbrueggen
> Yes it can be done, but yes it is more verbose, MUCH more verbose. I have
> implemented it in my code, and it requires 22 statements to declare the
> enumeration type, its parameters, the controlling variable, and the overload
> functions necessary to allow equality and non-equality checks. All this to
> do what Pascal allows in one statement!
But as all that is in a module that can be re-used, and the application side
is very similar to Pascal code, I would consider this only a minor issue. The
point is that it can be done at all...
Jan
Paul van Delst
>
> "Arjen Markus" <Arjen....@wldelft.nl> wrote in message
> news:3BF3E44F...@wldelft.nl...
>
> <snip>
> >
> > 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).
>
> Yes it can be done, but yes it is more verbose, MUCH more verbose. I have
> implemented it in my code, and it requires 22 statements to declare the
> enumeration type, its parameters, the controlling variable, and the overload
> functions necessary to allow equality and non-equality checks. All this to
> do what Pascal allows in one statement!
>
> And even then it will only allow comparisons in IF statements, you cannot
> use a SELECT CASE unless you allow the enumeration type to be public, which
> defeats the purpose because it allows comparison against integer constants.
>
> Here's my implementation, maybe someone can spot something I'm missing...
> (sorry if the indentation etc is wrong, I'm posting this from a different
> news reader than usual):
You call your example verbose? I thought it was particularly succinct and quite clear - at
least, I could tell what you were doing (I didn't know what the meaning of enumerated types
meant until reading this thread.)
cheers,
paulv
--
Paul van Delst Religious and cultural
CIMSS @ NOAA/NCEP purity is a fundamentalist
Ph: (301)763-8000 x7274 fantasy
Fax:(301)763-8545 V.S.Naipaul
Richard Maine
> Richard Maine <nos...@see.signature> writes:
>
> > 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.
>
> Isn't that only because mixing numeric and character variables in COMMON isn't
> standard-conforming in any case, and for EQUIVALENCE purposes, the compiler
> doesn't have to support mixing numeric and character data here as well?
I don't think so. In fact, I don't think that restriction even exists
any more in f90. Anyway, I don't see it in a quick scan. In f77,
there were only 2 sizes of storage units - character and numeric.
(Things could take multiple units, but the multiple was always
specified by the standard). Common blocks were segregated by that.
In f90, there are innumerable sizes with unspecified relationships.
In f90, you are allowed (anyway I think so - someone correct me if
I've missed it) to mix all types in the same common block. You
just have to make sure that things of one type of storage unit
only get associated with things specified by the standard to be of the
same size storage unit.
For example, you can have a default integer overlaid with a default
real, as they are specified to both occupy one numeric storage unit.
But you can't have a character*4 overlay a default integer because
that might not be the right size (you can't assume that you know
that 4 characters are as big as a default integer).
Anyway, back to the case I was talking about. The "obvious" thing I
was referring to is something like
type my_type
sequence
integer(some_kind) :: i
integer(another_kind) :: j
end type
type(my_type) :: structure
common /com/ structure
..... ! In some other scoping unit
integer(some_kind) :: l
integer(another_kind) :: m
common /com/ l,m
Some of the matierial I cited says that this is allowed only if
some_kind and another_kind are both the kind for default integer.
But the other material I cited seems to say that the storage
layout is forced to be such that this would work if it were
allowed.
James Giles
"Colin Watters" <co...@bjalondon.com> wrote in message
news:9t2tei$gqt$1...@news.sinet.slb.com...
...
> Yes it can be done, but yes it is more verbose, MUCH more verbose. I have
> implemented it in my code, and it requires 22 statements to declare the
> enumeration type, its parameters, the controlling variable, and the overload
> functions necessary to allow equality and non-equality checks. All this to
> do what Pascal allows in one statement!
Yes, having a way to emulate a feature is not as good as having the
feature. This is a paraphrase of something one of my old bosses used
to say: "Having a solution to a problem is not nearly as good as not
having the problem."
> And even then it will only allow comparisons in IF statements, you cannot
> use a SELECT CASE unless you allow the enumeration type to be public, which
> defeats the purpose because it allows comparison against integer constants.
Of course, the difficulty here is that the feature is proposed to be added
to the next version of the language standard *without* any protection
against mixed type comparisons! So, you'll still have to use your emulation
even after the feature is ostensibly available in the language. Sounds
like you're one of those that should write a critical public review comment
when the time comes. In fact, I'm hoping that most people will oppose
the feature as it's currently proposed. It would be better not to have the
feature at all than as currently written.
--
J. Giles
Christopher Eltschka
[...]
> 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.
That's a strange decision, given that even C++ (a C family member!)
has safer enumerations than C (though still less safe than Pascal):
enum color { red, green, blue };
color c;
int i;
c = red; // Ok
c = 0; // Error (would be allowed in C)
c = color(0); // Ok
i = red; // Ok
Is the choice for f2k already fixed, or could it still happen that at
least the C++ model is adopted (if not the Pascal model, which would
be even better)?
I've read in another part of the thread that C compatibility was one
concern. C++ enums should of course be completely compatible with C
enums. That is, if you include a C header with an enum definition, you
can pass enums of that type to a C function using the same definition
(assuming they have a compatible ABI, which on current operating
systems usually is the case because the OS API is generally a C
interface).
James Giles
"Christopher Eltschka" <celt...@web.de> wrote:
> "James Giles" <james...@worldnet.att.net> writes:
>
> [...]
>
> > 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.
>
> That's a strange decision, given that even C++ (a C family member!)
> has safer enumerations than C (though still less safe than Pascal):
> Is the choice for f2k already fixed, or could it still happen that at
> least the C++ model is adopted (if not the Pascal model, which would
> be even better)?
Well, it's too late for any better version to be adopted
for the next standard. That would require changes to
several parts of the proposed document and it's already
being proof-read for submission to the final approval
process - which involves a public review. It's not too
late to remove the present version of the feature from the
document. It is small and has very little interaction with
other parts of the language. I'm hoping that the public
review will draw sufficiently negative comments on this
feature that it will indeed be removed. Then a future
version of the standard can actually contain a more useful
version of the feature.
--
J. Giles