Implementing JAVA interfaces in FORTRAN 20xx

On 26 août, 01:33, e p chandler <e...@juno.com> wrote:
> On Aug 25, 8:17 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
>
>
> > e p chandler wrote:
>
> > (snip)
>
> > > Please explain how this does any real good in Fortran at all. As I
> > > understand it, you can not pass an array of integers to a routine
> > > which expects an array of elements, each of which is of derived type,
> > > each of which consists only of an integer.
>
> > In Java, you can't have arrays of objects, but only
> > arrays of object reference variables. The closest you
> > would get in Fortran would be arrays of pointers.
> > Oops, no arrays of pointers, arrays of structures
> > containing pointers.
>
> > Now, can you use a pointer to integer equivalently
> > to a pointer to a structure containing only an
> > integer? Or one with the integer at the beginning?
>
> > -- glen
>
> I just want to
>
> call wonder_routine(int_array)
>
> where int_array is an ordinary array of integers. I don't care what
> the routine does underneath. I do know that I get a type mismatch
> error when I pass an array of integers to a routine expecting an array
> of a derived type.
>
> So right now I'm close to serious mirth when what I thought was a
> relatively straight forward question about Fortran is answered in
> terms of Java _and_ the properties of pointers in C! :-)
>
> - e

You might try to solve the problem with an equivalence :

TYPE :: integer_type
SEQUENCE
INTEGER :: value
END TYPE

integer :: vector(10)
type(integer_type) :: other(10)
equivalence (vector,other)

!.. you fulfill vector

CALL wonder_routine(other)

fj <francois.jacq@irsn.fr> wrote:

> You might try to solve the problem with an equivalence :
>
> TYPE :: integer_type
> SEQUENCE
> INTEGER :: value
> END TYPE
>
> integer :: vector(10)
> type(integer_type) :: other(10)
> equivalence (vector,other)
>
> !.. you fulfill vector
>
> CALL wonder_routine(other)

I've not quite figured out what the purpose behind this all was supposed
to be anyway, but note that as soon as you make a derived type a
sequence type, it is not extensible. This might defat the whole point,
if I've correctly guessed the objective (which I might not have).

This is, of course, in addition to the mant, many other "issues" with
equivalence.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

On 26 août, 18:42, nos...@see.signature (Richard Maine) wrote:
> fj <francois.j...@irsn.fr> wrote:
> > You might try to solve the problem with an equivalence :
>
> > TYPE :: integer_type
> > SEQUENCE
> > INTEGER :: value
> > END TYPE
>
> > integer :: vector(10)
> > type(integer_type) :: other(10)
> > equivalence (vector,other)
>
> > !.. you fulfill vector
>
> > CALL wonder_routine(other)
>
> I've not quite figured out what the purpose behind this all was supposed
> to be anyway, but note that as soon as you make a derived type a
> sequence type, it is not extensible. This might defat the whole point,
> if I've correctly guessed the objective (which I might not have).
>
> This is, of course, in addition to the mant, many other "issues" with
> equivalence.

Even if the "integer_type" I propose only extends an abstract type
like "ordered_type" ?

This might be related to the implementation of derived types which
extends another type. But if this other type is abstract then there is
no data inheritance. Therefore I have a question for compiler
programmers :

Is there any additional information stored into my "integer_type" if I
declare it extending "ordered_type" ?

This is perhaps also related to the more general question :

Are the pointers to the procedures bound to a type stored into the
objects of that type or is the choice the right routine (when
resolving a calling sequence) just a compilation task ?

>
> --
> Richard Maine | Good judgement comes from experience;
> email: last name at domain . net | experience comes from bad judgement.
> domain: summertriangle | -- Mark Twain

fj <francois.jacq@irsn.fr> wrote:

> On 26 août, 18:42, nos...@see.signature (Richard Maine) wrote:
> > fj <francois.j...@irsn.fr> wrote:
> > > You might try to solve the problem with an equivalence :
> >
> > > TYPE :: integer_type
> > > SEQUENCE
> > > INTEGER :: value
> > > END TYPE

> > but note that as soon as you make a derived type a
> > sequence type, it is not extensible.

> Even if the "integer_type" I propose only extends an abstract type
> like "ordered_type" ?

You didn't show it extending anything, so I was talking about it being
extensible instead of about it being an extended type that extends
something else. I'm moderately (though not 100%) sure that an extended
type also cannot be a sequence type. The question of whether it is
extending a concrete or abstract type would not be relevant to that.

I forget the details, but my understanding was that there were reasons,
both in implementation and in concept, why it can't work (or at least
would make for a mess) for sequence types to be involved in inheritance.

Recall that the main point of sequence types is that you can have
different declarations count as the "same" type, thus allowing type
conformance between different scoping units without them having to USE a
common module to acess the same type definition. I seem to recall that
sequence types were added so that people didn't *HAVE* to use modules
for derived types (though it is still a lot more convenient to do so).
Sequence types can be used for other reasons as well (such as your
equivalence stuff), but I'd call the other stuff peripheral to that
basic functionality of sequence types. So imagine the mess from having
multiple definitions of a sequence type and also having those multiple
definitions involved in inheritance trees.

I also think that things like SELECT TYPE have implementation "issues"
if polymorphic things could be of a sequence type.

You'll probably have top ask an implementor (which I suppose you were
doing) if you want more detail than that.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

On 2008-08-26, fj <francois.jacq@irsn.fr> wrote:
> This might be related to the implementation of derived types which
> extends another type. But if this other type is abstract then there is
> no data inheritance.

"data inheritance" isn't, AFAICT. Data is always replicated for each
instance/object/whatever you want to call it/. The problem is type-bound
procedures (virtual functions in C++, in case you're familiar with
that).

> Therefore I have a question for compiler
> programmers :
>
> Is there any additional information stored into my "integer_type" if I
> declare it extending "ordered_type" ?
>
> This is perhaps also related to the more general question :
>
> Are the pointers to the procedures bound to a type stored into the
> objects of that type or is the choice the right routine (when
> resolving a calling sequence) just a compilation task ?

The crucial thing is that F2003 supports dynamic polymorphism, meaning
that the procedure is selected at runtime (again, the equivalent C++
terminology is "virtual function"). This is typically (in C++ but
probably in most F2003 compilers as well) implemented via a "virtual
function table", or vtable for short, which is a table for each class
that contains the addresses of the virtual functions. A derived type
whose class contains type-bound procedures contains not only the data,
but also the address of the vtable. For an example, see e.g. this ABI
description (this is what Linux does for C++)

http://www.codesourcery.com/public/c...vtable-ex.html

Now, as F2003 doesn't support multiple inheritance, it can be somewhat
simplified compared to the above, but I'd guess the basics are the same.


--
JayBee

Richard Maine wrote:
(snip)

> I forget the details, but my understanding was that there were reasons,
> both in implementation and in concept, why it can't work (or at least
> would make for a mess) for sequence types to be involved in inheritance.

For C struct, it is guaranteed that a pointer to a struct
is equivalent to a pointer to its first member. A struct
can be extended by creating a new struct with the old struct
as its first member. I have seen it done. This would
presumably also be true for Fortran structures with
C interoperability such that they would work with the
corresponding C struct. That might require using C_LOC
and C_F_POINTER, such that one was working with real
C pointers.

> Recall that the main point of sequence types is that you can have
> different declarations count as the "same" type, thus allowing type
> conformance between different scoping units without them having to USE a
> common module to acess the same type definition. I seem to recall that
> sequence types were added so that people didn't *HAVE* to use modules
> for derived types (though it is still a lot more convenient to do so).
> Sequence types can be used for other reasons as well (such as your
> equivalence stuff), but I'd call the other stuff peripheral to that
> basic functionality of sequence types. So imagine the mess from having
> multiple definitions of a sequence type and also having those multiple
> definitions involved in inheritance trees.

-- glen

On Tue, 26 Aug 2008 12:50:20 -0800, glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

> Richard Maine wrote:
> (snip)
>
> > I forget the details, but my understanding was that there were reasons,
> > both in implementation and in concept, why it can't work (or at least
> > would make for a mess) for sequence types to be involved in inheritance.
>
> For C struct, it is guaranteed that a pointer to a struct
> is equivalent to a pointer to its first member. A struct

Unless a bitfield, and equivalent but not identical: you must convert
and the _converted_ pointer is guaranteed to point (correctly) to the
first member or the struct. This is because C allows pointers to
different types to have different representations and even sizes.

> can be extended by creating a new struct with the old struct
> as its first member. I have seen it done. This would
> presumably also be true for Fortran structures with
> C interoperability <snip>

Although this means that you have to access (at least in the C code)
the older parts as v1.foo, or v2.v1.foo, etc. ad nauseam. Unless you
have anonymous (sub)structs, as GCC does.

In practice you can just add members to the end. C guarantees that if
two structs begin with members with the same types (and bitwidths if
used), they are laid out the same up to the first difference, which
includes (all of) one as a prefix of the other -- IF the two structs
are used in a union -- but that union could be in another translation
unit that hasn't even been written yet, so in practice the compiler
ignores that 'IF'.

- formerly david.thompson1 || achar(64) || worldnet.att.net

David Thompson wrote:
> On Tue, 26 Aug 2008 12:50:20 -0800, glen herrmannsfeldt
> <gah@ugcs.caltech.edu> wrote:
>
>
>>Richard Maine wrote:
>>(snip)
>>
>>
>>>I forget the details, but my understanding was that there were reasons,
>>>both in implementation and in concept, why it can't work (or at least
>>>would make for a mess) for sequence types to be involved in inheritance.
>>
>>For C struct, it is guaranteed that a pointer to a struct
>>is equivalent to a pointer to its first member. A struct
>
>
> Unless a bitfield, and equivalent but not identical: you must convert
> and the _converted_ pointer is guaranteed to point (correctly) to the
> first member or the struct. This is because C allows pointers to
> different types to have different representations and even sizes.
>
>

Is that the terminology used (bit field)? Does that refer to a complete
entity or a subregion of an entity? In most usages of the term that
I've seen, a "field" is a subregion of some larger entity. I think of a
field as a substring within a bit "string". I wish we could standardize
these things.

<snip>
> - formerly david.thompson1 || achar(64) || worldnet.att.net


--

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

glen herrmannsfeldt wrote:

> Gary Scott wrote:
> (snip)
>
>> Is that the terminology used (bit field)? Does that refer to a
>> complete entity or a subregion of an entity? In most usages of the
>> term that I've seen, a "field" is a subregion of some larger entity.
>> I think of a field as a substring within a bit "string". I wish we
>> could standardize these things.
>
>
> Bit field is a C term where you can give a name to some bits of
> (usually) an int variable in a struct. The complication is that
> which bits you get is implementation dependent.
>
> struct preferences {
> unsigned int likes_ice_cream : 1;
> unsigned int plays_golf : 1;
> unsigned int watches_tv : 1;
> unsigned int reads_books : 1;
> };
>
> (from http://en.wikipedia.org/wiki/Bit_field )
>
> The four variables are single bits of one unsigned int,
> but the standard doesn't specify which.

Hmm, less useful than I would ordinarily like. I usually need to
specify exactly which bit in order to match external DMA hardware.
Otherwise, that's similar to my prior hairbrained bitstring proposal.

>
> -- glen
>


--

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

Gary Scott wrote:
(snip)

> Is that the terminology used (bit field)? Does that refer to a complete
> entity or a subregion of an entity? In most usages of the term that
> I've seen, a "field" is a subregion of some larger entity. I think of a
> field as a substring within a bit "string". I wish we could standardize
> these things.

Bit field is a C term where you can give a name to some bits of
(usually) an int variable in a struct. The complication is that
which bits you get is implementation dependent.

struct preferences {
unsigned int likes_ice_cream : 1;
unsigned int plays_golf : 1;
unsigned int watches_tv : 1;
unsigned int reads_books : 1;
};

(from http://en.wikipedia.org/wiki/Bit_field )

The four variables are single bits of one unsigned int,
but the standard doesn't specify which.

-- glen