Newsgroups: comp.lang.apl
Path: watmath!watserv2.uwaterloo.ca!torn!cs.utexas.edu!wupost!csus.edu!sfsuvax1.sfsu.edu!emclean
From: emclean@sfsuvax1.sfsu.edu (Emmett McLean)
Subject: Re: J Suite vs cond
Message-ID: <1992Dec2.201058.5543@csus.edu>
Keywords: J, control, loop
Sender: news@csus.edu
Organization: San Francisco State University
References: <1992Nov30.203655.1043@Trirex.COM>
Distribution: na
Date: Wed, 2 Dec 1992 20:10:58 GMT
Lines: 105

>A paradigmatic function in Scheme might be the following, which returns  
>true if the input is a list of atoms, and returns false otherwise:
>
>(define lat?
>  (lambda (a)
>    (cond
>      ((null? a)	#t)
>      ((atom? (car a))	(lat? (cdr a)))
>      (else		#f))))
>
>In J, I (naively) only know how to express this as an explicit definition  
>which uses labels for readability and suite reassignment.  Not only does  
>this not look nice, I have to reinvent the label/suite assignment every  
>time I have one of these functions, plus the code is relatively  
>inefficient since I am not enjoying the tacit semi-compilation feature.
  
Below is the explicit verb for lat? . It doesn't look too bad.
For me "reinventing the suite assignment" is not a big ordeal.
Also, the main advantage of tacit programming is modularity.
The fact that tacit verbs marginally outperform their similar
explicit counterparts is a consequence of functional capability
of the language.

   isatom =. 0&=@#@$@>@{.
   isnull =. 0&=@#
   la =. i. 0 0
   la =. la, '$. =. 1 + isnull y.'
   la =. la, '0:`(la@}.)@. isatom y. ' 
   la =. la, 'y. =. 1'
   la =. la : ''
   
   s =. 2 ; 3 4 ; 5
   t =. 2 ; 3 ; 5 
   
   la s
0
   la t
1

>What I'm interested in is your answer to these questions:
>
>1) Is there another general way of cond-less programming that is easy to  
>do in J?

  How about?
   
   isatom =. 0&=@#@$@>@{.
   isnull =. 0&=@#
   lat =. 0:`(lat@}.)@.isatom`1:@.isnull

   s =. 2 ; 3 4 ; 5
   t =. 2 ; 3 ; 5 
   lat s
0
   lat t
1
   
>
>2) I believe that the suite is a neat feature in J, but it does not help  
>the programmer by capturing patterns of reuse that are typically needed.   
>Forks and trains simplify code by capturing patterns of function  
>application (good!), but there is no mechanism for recapturing common  
>patterns of suite assignment such as while/for/cond (bad!), thus leading  
>to increased use of explicit definition and individual stylistic solutions  
>that are not commonly shared by a community of language readers.
>

 Have you possibly overlooked the while construct: "f ^: g y", which
 executes "f y" while "g y" is zero until "g y" is 1 ? (For example
 ">:^:(10&~:) 3" is "10".)

 Wouldn't you agree that the construct: "f ^: n y", implements for
 effectively?   

 Similarly agenda implements cond fairly well.

 Regarding individual styles, wouldn't you agree that the explicit
 version of "lat?" is easy to follow? I would say it's format is
 similar to other recursive functions I've seen written by programmers
 in the J community.

>Does J need a cond conjunction (or whatever) of some sort to  
>simplify/clarify branching behaviour?
 
 I think the clarity issue may be a matter of getting used to
 something. Also, the do instruction along with suite provide
 alot of versatility.  (Have you experimented with some examples
 where branching to any one of several labels is contingent 
 on a particular input?)
>
>Suite is a great goto, but I don't have goto in Scheme (except call/cc  
>which is more powerful anyway), and I don't use goto's in C.  Is suite an  
>historical idea which should be dropped?
>
>Desperately trying to do word-at-a-time processing,

 Desparately trying to do list-at-a-time processing in a world
 where everyone wants me to do word-at-a-time and not too happy about
 it.
 
 Emmett 	:-)

 emclean@sfsuvax1.sfsu.edu
>
>
