🚀 go-pugleaf

Jim Giles:
   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.

APL does have shortcomings in this area.  But even APL has a method
for defining functions under program control.

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

define a set of arbitrary assertions (about code and data, e.g. x is
 a member of the set 5, 6, 7, 9)
trace execution until an assertion fails
allow programmer to modify program
allow programmer to continue execution from present location, or after
 backtracking, if desired.

This isn't a particularly outrageous specification -- even assembly
language programmers can do this sort of thing.

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

The advantage of an interactive session is that you don't have to
go through the process of writing programs to solve simple problems.
Note that shell languages address a similar need.

But by 'interface', I meant the ability to use facilities of the
language in the creation of what are usually called "macros".  
Note that macros allow for a certain consistency of result, similar in
some ways to the properties you appear to like about declarations.

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

Note that if you use access "functions" (verbs) for your global
variables you get similar properties.

   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 has not been around very long.  As of today, there are a few
features in the specification of the language which have not yet been
implemented.  APL programs are incredibly difficult to express in
ASCII.  I think this might be a better "explanation", if one were
needed.

On the other hand, I'm not so sure an explanation is needed.  From
what I understand, Fortran 90 has adopted a major part of the APL
language.

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