(j3.2006) liaison with H2

[Craig Dedo]

Everyone:
	Over the last few days, I have been looking into the Fortran binding
for SQL.  I am not done with my research but I have a few questions,
especially for Dan.  

	I will be gone on personal business for the rest of the day.  I hope
to have all of my thoughts on this issue written down sometime over the
weekend.  I will provide the references and supporting detail for my remarks
below when I can compose a complete reply.  

	I have some serious concerns about the general direction of Dan's
thoughts.  These are based on my direct personal experience with SQL
programming since 1996, most of it in commercial manufacturing applications,
with real profit-and-loss responsibility and real money at stake.

	Dan and anyone else who wants to reply, please answer my questions
to the best of your ability.

-----Original Message-----
> From: j3-bounces at j3-fortran.org [mailto:j3-bounces at j3-fortran.org] On
Behalf Of Dan Nagle
> Sent: Tuesday, May 27, 2008 06:59
> To: J3 List
> Subject: (j3.2006) liaison with H2

> Hello,

> I have been in contact with the Chair of H2.
> In short, H2 would like to continue the liaison with J3,
> on the grounds of their Fortran binding.

> This binding has a number of properties that are not good,
> from a Fortran point of view:

> 1. It relies on a preprocessor and applies to fixed-format only.

	The restriction to fixed-format is not true.  The current version of
the language bindings is 2003.  The Fortran binding has a normative
reference to Fortran 95.  The use only of fixed-format in implementations of
the Fortran binding is only due to the developers of those bindings choosing
not to support free format.

	What is wrong with the use of a pre-processor?  All of the language
bindings, except for Java, use a pre-processor.  This includes the binding
to Ada 95 and the binding to C.

> 2. It ignores interoperability with C, where C may have a more
>     up-to-date binding.

	The C binding is of the same nature as the Fortran binding.  The
only differences are:
	1.  The C binding makes full use of all of the features of C99,
whereas the Fortran binding does not make full use of all of the features of
Fortran 95.
	2.  Many more databases implement the C binding but do not implement
the Fortran binding.

> 3. It ignores modules, which are the preferred means of specifying
>     a Fortran binding.

	Why are modules preferred?  Modules encapsulate data definitions and
procedures.  They do not have the ability to provide the SQL programmer what
he or she really wants, i.e., to use SQL within a program directly and
intuitively.  This means easy and intuitive access to four main
capabilities:
	1.  Write SQL statements into the source code just like the
programmer writes source code in the host language.  This is called
"embedded SQL".
	2.  Construct and execute SQL statements at run time.  This is
called "dynamic SQL".
	3.  Call SQL stored procedures just like the programmer would call a
procedure in the host language.
	4.  Full support of all extensions to standard SQL that the database
provides.

	The current pre-processor based approach already supports all of
these capabilities.  I don't know if a module approach could.

> 4. It ignores the object-oriented features of Fortran, which are
>     likely useful for database access.

	Yes, they are, but right now, only the Java-based Object Language
Binding (OLB) supports this.  I have not had the time to study it yet.

> In light of the above, if H2 is unwilling to modernize
> their Fortran binding, I would like to end the liaison
> regardless of H2's preferences.  The binding is simply too obsolete
> for any future consideration, and refusal to modernize it
> implies, to me, a lack of interest.

	The obsolete part is that the current Fortran binding does not
provide full support for the modern features of Fortran 95 and Fortran 2003.


	When I was the H2 liaison, I talked with the then chair of H2,
Donald Deutsch.  He told me that the members of H2 simply did not have the
necessary expertise in Fortran and that was the only reason that the Fortran
binding was not being updated.  They were interested, but needed the help of
J3 members or other Fortran experts.

> By "modernize" I mean "rewrite as an (optional) module".  Of course,
> I'm very open to other interpretations.  :-)

	I don't know if a module approach could provide the capabilities
that SQL programmers need.  

	Based on my preliminary study, it may be possible to update the
current binding to provide support for the new features of modern Fortran.
Right now, it does not look like that big of a change.  

> Does anyone disagree?

> Does anyone know of an implementation of the SQL binding for Fortran?

	As I mentioned in a previous reply to this message, Oracle/Rdb for
OpenVMS has bindings for almost all of the supported languages:  Ada, Basic,
C, Cobol, Fortran, and Pascal.  I don't know about MUMPS (or M).  IIRC, the
regular Oracle for OpenVMS only supports the C binding.  

> TIA

> -- 
> Cheers!
> Dan Nagle


Sincerely,
Craig Dedo
17130 W. Burleigh Place
P. O. Box 423                       Voice Phone:  (262) 783-5869
Brookfield, WI   53008-0423  Fax Phone:  (262) 783-5928
USA                                     Mobile Phone:  (414) 412-5869
E-mail:  <cdedo at wi.rr.com> or <craig at ctdedo.com>