🚀 go-pugleaf

Jim Giles:

Raul Deluth Miller-Rockwell:
   |> 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.

The Fortran standard also fails to specify the means by which text
which represents a Fortran program is converted to executable form.
Which means that any tools which depend on this process are
necessarily non-portable.

   |> 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.

How does this help you write development tools in Fortran?  You're
saying you'll have to develop text-editting facilities as a
pre-requisite for any such tools?

   |> 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.

I don't mean self-modifying code.  I mean code useful in the
development process.

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

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

The J interface (and, to a lesser degree, the APL interface) is a part
of the language standard.  Similar statements apply for Lisp (though
there is quite a bit of variation between languages which are called
"Lisp").  I'm not aware of any such standards for Ada or Algol.

   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.

Obviously, there are many people who disagree with you.

   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.

Hmmph... Fortran is not very amenable to data-driven programming.  I'm
sure not going to go to the effort of building a whole bunch of tools
to support my programming style in Fortran when I can write a special
case solution for whatever it is that I've been asked to code into
Fortran.

Beyond that, I think your opinion is formed by the languages you're
working with.  Certainly, your opinions are valid for Fortran and ADA
programing.

On the other hand, I find exploratory programming to be quite useful.
There are many cases where I'll spend most of my time designing, and
only a short bit of time entering and executing the code.  But this
requires a certain amount of familiarity on my part with the problem
space.

-- 
Raul Deluth Miller-Rockwell                   <rockwell@socrates.umd.edu>