Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!know!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!psuvax1!rutgers!aramis.rutgers.edu!klaatu.rutgers.edu!josh
From: josh@klaatu.rutgers.edu (J Storrs Hall)
Newsgroups: comp.lang.apl
Subject: Re: Compilability (was: Interesting feature of J)
Message-ID: <Sep.28.16.41.13.1990.285@klaatu.rutgers.edu>
Date: 28 Sep 90 20:41:18 GMT
References: <Sep.25.16.10.08.1990.1736@klaatu.rutgers.edu> <1990Sep28.155915.2424@water.waterloo.edu>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 44

ljdickey writes:

   nub0 =. '( ( i. # y. ) = i.~ y.) # y.' :: ''

   nub1 =. #~ i.&# = i.~

I would assume any good compiler would reduce either of these
definitions to the dataflow graph:

	    value
	       \
		#
	       / \
	      =	  \
	     / \   \
	    i.  i.  \
	     \  /\  /
	      # \/ /
	       \/ /
		\/
		 \
		 argument

and produce identical code for each.  The only problem the '...'::''
form might produce is that a name used in the code might change 
definition sufficiently to invalidate the original parse of the
string.  APL has this problem (problem from the compiler writer's
point of view), but few other languages do.  Even in Scheme, where 
function definitions can be thrown around with mad abandon, reparsing
is never necessary.

However, what I meant by my original remark was that J has even 
fewer of the kinds of dependencies between code and actual data
type and shape and size, than APL does.  An APL compiler (like 
Tim Budd's) depends heavily on gleaning "clues" from the code
about the size and shape of the data.  

From the programmer's point of view, of course, this is very 
laudable:  the J program for nub you exhibited works on a range
of data it would take several APLSV programs to cover, or dozens
of C programs.  The necessary concommitant is that the compiler
has to be able to extract all of those programs from the J code.

--JoSH