Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!dali.cs.montana.edu!milton!whit
From: whit@milton.u.washington.edu (John Whitmore)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran -vs- C (yet again)
Summary: Suggestions for expansion of the languages.
Message-ID: <11977@milton.u.washington.edu>
Date: 30 Nov 90 02:21:55 GMT
References: <1990Nov24.002836.19739@ariel.unm.edu> <1270009@hpcllmv.HP.COM> <771@sarnoff.sarnoff.com>
Organization: University of Washington, Seattle
Lines: 55

In article <771@sarnoff.sarnoff.com> hht@sarnoff.sarnoff.com (Herbert H. Taylor   x2733) writes:
>
>I would like to see this discussion move from "IS Fortran or C better"
>to "WILL Fortran or C BE better" in the future ...

	Finally, a topic I can really get behind!  Most languages have
some constructs that allow optional arguments: 

	OPEN(UNIT= the_unit, FILE='FileName',FORM='UNFORMATTED)

is a Fortran example.  Yet, this sort of 'keyword=value' calling
sequence is not supported for user subroutines.  The language implementors
needed it; SO DO THE USERS.  

	CALL READ_THE_FILE( file='FileName', 
	&	format='Bruce''s third generation data set', 
	&	into= data_array(5)   )

	In fact, I've written similar calls in some of my code, in
Fortran, but it's terribly messy.  One has to pass strings and pick
out 'keyword=' strings and look at what follows 'em.  Making the
'keyword=' optional requires *sigh* yet more coding, and the usual
trauma of choosing a default.  The calling module, of course, makes
the string with a WRITE to some pre-allocated fixed length
string variable.

	Secondly: DATA initialization requires that action be taken
before a module is explicitly entered in the course of execution.
Even more useful would be an entry point which was invoked
only at startup of the image (so one could put any initialization
code a module needs, INSIDE the module, with complete assurance
that initialization would always precede any other executable code).
Why stop there?  Add a 'EXIT_HANDLER' entry point, so that any cleanup
of buffers that a module needs, will be queued for execution when
the image exits (for whatever reason).  No more improperly closed
files, or buffers left unflushed!  Many language implementations
have this already, of course, in somewhat clumsy form (at least
in VMS).  It's terribly useful, and there is no system-independent
way to do it in FORTRAN (or C, to my knowledge).  Surely, any 
reasonable operating system supports exit handlers?

	Third: it's damned near impossible to make an interactive
program without building in some way to fork-to-shell (on VMS, I
use a subprocess).  This allows a program user to peruse his
file directory for that name he'd forgotten how to spell, or read
his notes, or send some quick E-mail.  It's an essential part of
interactive programming (IMHO), but has never been included in
any system-independent way.  Add this to the language definition!
VMS and Unix have no problems with this sort of thing; even my Macintosh
can do it.  BUT I have to recode the program each time I port it!


	These rantings brought to you by
	John Whitmore
	whit@milton.u.washington.edu