Newsgroups: comp.lang.apl
Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!tmsoft!itcyyz!yrloc!hui
From: hui@yrloc.ipsa.reuter.COM (Roger Hui)
Subject: Re: what is j?
Message-ID: <1991May18.143707.3182@yrloc.ipsa.reuter.COM>
Reply-To: hui@yrloc.ipsa.reuter.COM (Roger Hui)
Organization: Iverson Software Inc.
References: <199113.993.337@canrem.uucp> <3970007@hpwrce.HP.COM> <1991May18.004902.29060@yrloc.ipsa.reuter.COM> <1991May18.042957.704@yrloc.ipsa.reuter.COM>
Date: Sat, 18 May 91 14:37:07 GMT

Reply to article by Robert Bernecky, 1991 May 18:

>Umm, err. "The following verbs are compiled". Please Explain. 
>My understanding ofcompilation is that you take advantage of knowledge about
>data types, rank, shape, etc,  to produce highly efficient code.
>Please tell me HOW J achieves this in tacit definition. It seems to me
>that tacit definition appears to be more like C macro expansion than
>compilation: e.g., destruction of any evidence of what you originally
>wrote, rather than true compilation(Destruction plus substantial
>performance improvement).

The verbs I cited are "compiled", in the sense that they are re-executed
without having to reparse the source.  The original question was "Is J
compiled or interpreted?", and I believe my description of J as an
interpreter with certain things compiled is fair and accurate.

Re your parenthetical definition of "true compilation" -- destruction
plus substantial performance improvement:  Some compilers bill themselves
as "optimizing compilers".  Does this mean that non-optimizing
compilers are not performing "true compilation"?  Whether something is 
a compiler is a matter of what methods are used to execute sentences.
While compiled code generally perform better than interpreted code,
the performance improvement is not a defining characteristic of a compiler.

As it happens, the technique that J uses for tacit defns does result in
measurable performance improvement, relative to the equivalent explicit defn.

>Furthermore, it appears to my naive view that Tacit Defn also 
>makes it impossiblw to debug a system unless you have maintained 
>source files for everything. For example, if you have  a defn for 
>a function "foo" which calls  "mean",and you define it using tacit defn,
>and LATER discover a bug in "mean", you end up fixing "mean", BUT
>"foo" is NOT fixed unless you recompile the universe.
>
>This strikes me as :
>a. making Real Programs, rather than Toy Programs, harder to develop and debug.
>b. Increasing the liklihood of bugs in Real Programs.

Well, one does maintain source files for C or Fortran or Pascal programs;
and if there is no "make" facility, then one would possibly recompile
everything.  (Does "true compilation" require a "make" facility?)  As well, 
the evoke (~) adverb in J allows avoiding this complete recompilation.

I am sure that YOUR compiler would address these issues.  Perhaps we can 
carry out further discussions offline.

-----------------------------------------------------------------
Roger Hui
Iverson Software Inc., 33 Major Street, Toronto, Ontario  M5S 2K9
(416) 925 6096