David Lambert actually described two suggestions. The first is to link an error back to the primitive that signaled the error. The second is to put spaces next to the primitive that signaled the error.
First, the second. This is actually already done. However, lying in bed this morning I realized that there is probably a bug in the determination of where the spaces are put in the error line. The following shows that spaces are currently already there: +/ % blah1&:blah2@:(%&3)@_1 2&p. |domain error | +/% blah1&:blah2@:(%&3)@_1 2&p. The problem is that the 3 spaces are between the % and blah1, whereas ideally they should be put closer to the @ . The first suggestion, linking an error back to the primitive that signaled the error, is harder, given the current structure of the implementation. For example, suppose the code for the dyad i. gets an error. However, that code can be invoked not just by the user executing i., but by other primitives such as e., f/., etc. Traditionally in APL (and J), because the environment is interpretive, a standard response to enhanced error reporting is to recommend techniques for isolating the error, such as entering pieces of the offending expression. ----- Original Message ----- From: Raul Miller <[email protected]> Date: Wednesday, February 10, 2010 6:38 Subject: Re: [Jgeneral] Two requests for j enhancement. To: General forum <[email protected]> > On Tue, Feb 9, 2010 at 6:55 PM, Roger Hui <[email protected]> wrote: > > > 1) There are no plans to do what you suggested, > > nor am I convinced by its benefits vs. its cost. > > > You are undoubtedly correct, but could you describe > those costs? > > Thank you, > > -- > Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
