> I believe that J's tacit form was designed to require a minimum of > symbols to represent general functions tacitly, given the constraints of > using only monadic and dyadic functions. From what I can tell, not much > thought was given to any requirement for simple methods to convert > between the two forms. This is just my impressions, however. Roger H. > could better expound on the tacit design goals, as he was in the middle > of the design process as J was built.
Ken did not set out to design tacit definition. If you are interested in the process please read the papers referenced in "From APL to J" http://www.jsoftware.com/jwiki/Essays/From_APL_to_J and also "Remembering Ken Iverson" http://keiapl.org/rhui/remember.htm ----- Original Message ----- From: Skip Cave <[email protected]> Date: Tuesday, April 28, 2009 20:13 Subject: Re: [Jchat] Language S To: Chat forum <[email protected]> > Don, > > Raul didn't say that there wasn't a tacit version of his example > algorithm. He simply stated that J's built-in explicit-to-tacit > translator won't translate that particular expression from > explicit to > tacit. The methodology to do that conversion is fairly complex, > and is > not easily coded into a programmable algorithm. Raul said he > could > create the tacit version of his example, but it would require > some > re-architecting of his function. > > I believe that this may be at the crux of one of your your > objections to > J's tacit syntax. You would like a tacit syntax that can easily > be > converted to and from the explicit form using a very few rules. > J's > tacit form is definitely not that. Some explicit expressions > (like > Raul's) require some re-thinking to put them in tacit form. > Simple rules > like "replace x with ], and y with [" are often > not possible when > converting J's explicit form to tacit, and vice versa. > > J's tacit syntax is a monument to brevity. Ken Iverson's > mathematical > background led him to focus on brevity and consistency in his > language > design. Roger took that torch, and has borne it forward. > > I believe that J's tacit form was designed to require a minimum > of > symbols to represent general functions tacitly, given the > constraints of > using only monadic and dyadic functions. From what I can tell, > not much > thought was given to any requirement for simple methods to > convert > between the two forms. This is just my impressions, > however. Roger H. > could better expound on the tacit design goals, as he was in the > middle > of the design process as J was built. > > The complexity of any process to convert explicit J expressions > to tacit > doesn't seem to be an issue in the language design. J's own > explicit-to-tacit converter can't convert many J explicit > expressions, > but that doesn't seem to be much of an issue with the J > community. I > read somewhere that J's explicit-to-tacit converter was de- > commissioned > at one time, specifically because it couldn't convert many > explicit > expressions. > > On the other hand, tacit symbol efficiency is apparently not one > of your > design goals. You would like a syntax that is easily converted > from > explicit to tacit with simple rules, regardless of how many > symbols are > required. > > Should tacit syntax be optimized for brevity, or optimized for > ease of > conversion to an explicit form? Which of these is a more > important > design goal, and what advantages each brings, is the core of the > issue. > Skip Cave > > <<<>>> > > Don Watson wrote: > > Hi Raul, > > > > Be reasonable. If your tacit won't > accept it, how do you expect mine to? > > > > Don ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
