Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!udel!haven.umd.edu!socrates.umd.edu!socrates!rockwell
From: rockwell@socrates.umd.edu (Raul Rockwell)
Newsgroups: comp.lang.apl
Subject: Re: what is j?
Message-ID: <ROCKWELL.91May18095711@socrates.umd.edu>
Date: 18 May 91 14:57:11 GMT
References: <199113.993.337@canrem.uucp> <3970007@hpwrce.HP.COM>
	<1991May18.004902.29060@yrloc.ipsa.reuter.COM>
	<1991May18.042957.704@yrloc.ipsa.reuter.COM>
Sender: rockwell@socrates.umd.edu (Raul Rockwell)
Organization: Traveller
Lines: 33
In-Reply-To: rbe@yrloc.ipsa.reuter.COM's message of 18 May 91 04: 29:57 GMT

Roger Hui:
   >a) J is an interpreter, but the subclass of verbs known as tacit
   >definitions are compiled.  For example, the following verbs are
   >compiled:
   >   square =. ^&2
   >   sqrt   =. ^&0.5
   >   norm   =. sqrt & (+/) & square

Robert Bernecky:
   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.

Don't forget knowledge of data values and, similarly, function
properties.  One of my favorite compiled functions, SORTCUT, is an
implementation of  '':(+/  @  (<:/)  &  (>./\) )"1

Now, the pre-processor and the main computation are both O(n^2), where
n is the number of elements in a list, but SORTCUT is O(n) :-)
It is true you get speedups from knowing type, rank, etc., but in this
case the big speed ups come from (*) knowing that >. is associative,
and (*) knowing that the result of >./\ is nondecreasing.

   Furthermore, it appears to my naive view that Tacit Defn also makes
   it impossible to debug a system unless you have maintained source
   files for everything.

er... but that's already covered by the language semantics.  Isn't it?

Raul Rockwell