🚀 go-pugleaf

In article <ROCKWELL.92Apr8165322@socrates.umd.edu>, rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) writes:
|> [...]
|> Is there a standard for interpreted Fortran?  [...]

The Fortran standard does not specify the means of implementation.
As such, any implementation - including an interpreter - which correctly
processes Fortran programs according to the requirements of the standard
is a standard conforming implementation.

|> [...]                                         Does it allow you to
|> write utilities in platform-independent Fortran for debugging?  Can
|> you mix interpreted and compiled Fortran [to obtain speed for commonly
|> repeated operations]?

Provided you find a Fortran interpreter, the answers are yes and yes.
At least, there is nothing in the standard which prohibits such.

|> [...]
|> How easy is it to change a declaration in interpreted Fortran, should
|> that declaration turn out to be a problem?  [...]

I suspect (not having seen an implementation) that it can be done
as easily as Basic interpreters do.  That is, edit the text of
the offending declaration and type `run' again, or `relink', or
whatever causes the new declaration to be incorporated in the 
existing program.

|> [...]                                    Can Fortran be used to
|> manipulate blocks of interpreted code?

You mean: self modifying code?  Bletch.  But obviously Fortran programs
can be written which edit Fortran source and cause a `relink' or whatever
the interpreter requires.

|> [...]
|> Or are you limited to whatever user interface your interpreted Fortran
|> vendor provides?

Just like J, APL, Ada, Lisp, Algol, ...?

|> [...]
|> What facilities does Fortran have to support interpreted interaction?
|> [Note: I've never seen a Fortran interpreter, and am not sure I'd
|> consider such a thing to be particularly useful.  The design of
|> Fortran seems, to me, to demand more "batch-oriented" debugging
|> techniques.]

And indeed that is a superior method.  This interactive `session' 
pocket-calculator approach to programming languages leaves me cold.
I've never seen a Fortran interpreter either.  One is certainly
possible.  I don't think it's desirable for _any_ language to be 
interpreted.

In code development, you should write your algorithm before you even 
select your programming language.  You should write complete code
(or, at least, stand-alone code portions) before even firing up
the language processor once.  Hacking out algorithms in an interactive
`session' is not even programming in my view.

J. Giles