Re: Program Translation - Nov. 14, 2013
Roy Smith wrote: > In article , > Tim Prince wrote: > > > Perhaps you would start with an automatic indentation tool before > > translating. You may have a rule against using current syntax and > > indentation for Fortran, but others don't. > > Does anybody still use ratfor? No. Well, I suppose it is possible you might find a soul or two somewhere, but you'd have to look prety hard. Ratfor became essentially obsolete with Fortran 77. -- Richard Maine email: last name at domain . net domain: summer-triangle -- https://mail.python.org/mailman/listinfo/python-list
Re: Python/Fortran interoperability
sturlamolden wrote: > On 24 Aug, 02:26, nos...@see.signature (Richard Maine) wrote: > > > You missed the word "OOP", which seemed like the whole point. Not that > > the particular word is used in the Fortran standard, but it isn't hard > > to guess that he means a derived type that uses some of the OOP > > features. Inheritance, polymorphism, and type-bound procedure (aka > > methods in some other languages) come to mind. > > But C is not OOP. The ISO C bindings in Fortran are not ISO C++ > bindings. This is for a reason: C++ does not have a standard ABI like > ISO C. That seems irrelevant to the question originally asked, which was >>> Do you want to use Fortran derived types or Python classes that >>> contain type-bound procedures (including finalizers)? Yes, it is no surprise that the C interop stuff fails to address this, since it isn't in C. Something different/extra would be needed, which is exactly what Nick said. I'm going to jump out of the middle of this now. The only reason I jumped in was to point out the gap in communication, where Nick said that the TR doesn't handle "OOP derived types" and you replied that it does so do derived types, omitting the OOP part, which was clearly (to me) Nick's whole point. However, I don't seem to be facilitating the communication, as the replies just seem to be wandering farther afield, or maybe it is around in a circle. I think you just explained that the ISO C bindings in Fortran don't handle what Nick is asking about... but that somehow this makes it puzzling that Nick also says that they don't handle it. Well, I'll leave it to Nick and you, I guess. I'm lost. -- Richard Maine| Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain -- http://mail.python.org/mailman/listinfo/python-list
Re: Python/Fortran interoperability
sturlamolden wrote: > Does anyone use OOP in Fortran anyway? Presumably not many people yet because... > And Fortran 2003 compilers are not ubiquitous. I'd not only agree, I'd say that was quite a bit understated. Last time I checked, the number of Fortran 2003 compilers available on the most widely used platforms was zero, which is quite a bit short of ubiquitous. No I don't have an IBM workstation handy; or a Cray. Nor do most people. I did try playing with the Fortran OOP stuff quite a few years ago, when NAG first added some of the OOP features to their f95 compiler. But alas, although they added some of the OOP features, there were critical parts that were not included. Play with it a little is all I could do. I couldn't write any serious code, or even "play" very extensively. (Lack of allocatable scalars was a show stopper; it seems so simple and isn't even normally identified as an OOP feature per se, but you need it to do much with OOP in F2003). I'm told that NAG's 5.2 finally has the needed stuff, but it has been an awful long time in coming... and still isn't yet here for anything but Linux (I'm told "soon"). Some other compilers are also getting there. But there is just no way that most people have spent much time developing with compilers that adequately supported the f2003 OOP features. (I'd cite my formal comment on f2008, and maybe David Muxworthy's recent article as well, but we've already been down that path.) -- Richard Maine| Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain -- http://mail.python.org/mailman/listinfo/python-list
Re: Python/Fortran interoperability
sturlamolden wrote: > You also said we can only interop with > length-1 character strings. My kludge was valid Fortran and works with > strings of any length up to some sane limit that you can specify. There might be a confusion here (and I'm not even sure on whose part) on a picky but important detail of wording. I have seen multiple people confused by this one before. In fact, some potential confusion was forseen, which is why there are notes specifically about it in the Fortran standard (see below). Those notes do tend to get overlooked though. Only character strings of length 1 are interoperable, as the term "interoperable" is defined in the Fortran standard. However, that does not mean that only character strings of length 1 will work with C. The distinction might be picky, but it is important. See Note 15.19 (which in turn cites an example in Note 15.23) of f2003. You can pass a Fortran string of length n as an actual argument corrseponding to a dummy argument that is an array of n character*1 elements. This isn't considered a question of "interoperability", as it is a feature purely within Fortran, but it does impact on what kinds of things work. One might plausibly regard this as a kludge, but it is a kludge that is part of the Fortran standard and is guaranteed to work with all Fortran compilers. I almost said all f2003-compliant compilers (admittedly a limited set), but then I recalled that the feature actually dates back to f77 when character type was introduced; f2003 just extends it to the C character kind for the obscure case where the C character kind might be different from the default character kind (I don't know of any compilers where this is so, but the standard allows for it). -- Richard Maine| Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain -- http://mail.python.org/mailman/listinfo/python-list
Re: Python/Fortran interoperability
James Van Buskirk wrote: > "Richard Maine" wrote in message > news:1j4y84p.v5docbtueccmn%nos...@see.signature... > > > One might plausibly regard this as a kludge, but it is a kludge that is > > part of the Fortran standard and is guaranteed to work with all Fortran > > compilers. I almost said all f2003-compliant compilers (admittedly a > > limited set), but then I recalled that the feature actually dates back > > to f77 when character type was introduced; f2003 just extends it to the > > C character kind for the obscure case where the C character kind might > > be different from the default character kind (I don't know of any > > compilers where this is so, but the standard allows for it). > > No, this is a tricky point. It was allowed in f77 to pass an array > actual argument to a scalar character dummy argument, but the ability > to pass a scalar character actual argument to an array dummy argument > is new to the sequence association rules of f2003. So your first > impression was more accurate than the result of thoughtful reflection :) Ah. You might be right - probably you are. I know there is some closely related stuff that goes back a ways and was just extended to the C character kind in f2003, but it might not have been that exact bit. I'm probably thinking of the rule for sequence association that allows the character length parameter to differ between the actual and dummy... as long as you are doing sequence association. But it might be a new rule that puts the scalar case under sequence association; that's probably it. Not worth dragging out the standards to check, but I bet that's it. -- Richard Maine| Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain -- http://mail.python.org/mailman/listinfo/python-list
Re: Python/Fortran interoperability
sturlamolden wrote: > On 23 Aug, 20:42, n...@cam.ac.uk wrote: > > > That is precisely what I am investigating. TR 29113 falls a LONG > > way before it gets to any of the OOP data - indeed, you can't even > > pass OOP derived types as pure data (without even the functionality) > > in its model. Nor most of what else Python would expect. > > I am note sure what you mean. ... > You thus can pass derived types between C and Fortran. You missed the word "OOP", which seemed like the whole point. Not that the particular word is used in the Fortran standard, but it isn't hard to guess that he means a derived type that uses some of the OOP features. Inheritance, polymorphism, and type-bound procedure (aka methods in some other languages) come to mind. Since you say that you haven't used any of the F2003 OOP features, it isn't too surprising that you'd miss the allusion. -- Richard Maine| Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain -- http://mail.python.org/mailman/listinfo/python-list
