🚀 go-pugleaf

In article <ROCKWELL.92Apr9004048@socrates.umd.edu>, rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) writes:
|> [...]
|> 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.

I don't know about J, but APL does not specify how text is converted
to executable form either.  You could do it by black magic if you want, 
so long as the results of running the executable on valid data produce
the results the language definition says should be produced.

|> [...]
|> I don't mean self-modifying code.  I mean code useful in the
|> development process.

Give an example.  What have you got against examples?  You consistently
fail to be specific and/or fail to give an elucidating example.

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

I guess you've lost me and I no longer know what you mean by `interface'.
You'll have to give more specifics or an example.  If you mean that
the language is pocket-calculator `session' oriented, I don't believe
that confers _any_ advantage at all.

|> [...]
|> Hmmph... Fortran is not very amenable to data-driven programming.  [...]

Data driven programming is a useful concept but not a panacea.  One of 
the goals of our extension proposal is to make Fortran-like language(s)
more amenable to data-driven programming without removing the advantages
of procedural programming.

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

No, it's formed from the types of problems I wish to solve.  Given the
need to manipulate large arrays of floating-point numbers reliably,
the syntax of Fortran (plus our proposals) make more sense than J
does.  We seldom need to write a function which is generic to arrays
of all ranks (most finite difference algorithms, for example, have 
completely different properties on 3-d meshes than they have on 2-d 
or 1-d meshes).  We seldom need to write functions which are generic
to all numeric base types - an algorithm for complex manipulation
is usually considerably different from one limited to integers
or floating-point.  In these cases, we not only don't need to
define the functions to be generic, it would be a serious error
if someone tried to use them as if they were generic.  To be sure, 
it would be nice for those few functions that we do wish to make 
generic  if there was an easy way to do so (part of our proposal 
addresses this issue directly).

On the other hand, we do have large programs with hundreds (even
thousands) of procedures and tens of thousands of global variables
on which it is nice to have type checking done on automatically -
making sure I don't accidentally have two different definitions
of any procedure in the same program (making it ambiguous);
and providing a few common places in the text of the code in
which most of the properties of the global variables can easily 
be found; etc..

Then again, maybe this explains the continued success of Fortran-like
languages above APL/J style languages - even though the latter have
been around for 20 years.  (In this particular context - I shudder to 
think about it - even C is "Fortran-like" for the purposes of this
discussion, or Fortran is C-like, or something.)

J. Giles