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
