In order to know whether something is or is not significant for the implementation, you sometimes have to know quite a bit about the implementation. This matter is one of those times.
For the simpler case of reporting the name of the primitive for the error, without regard to whether it was called by something else, the interpreter needs to be modified in about 1000 places. The more complex case requires inspection and/or modification of an additional 2400 places. ----- Original Message ----- From: Raul Miller <[email protected]> Date: Wednesday, February 10, 2010 8:50 Subject: Re: [Jgeneral] Two requests for j enhancement. To: General forum <[email protected]> > On Wed, Feb 10, 2010 at 10:39 AM, Roger Hui <[email protected]> > wrote: > > 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. > > > > In other words, the cost here would be that > primitives would need two entry points? (One > where they retain their identity as a primitive, > for error reporting purposes and the other > where they do not?) > > That does indeed sound significant -- we > have a lot of primitives and we have monad > and dyad cases for each, and adding new > naming conventions and calling conventions > all takes time to set up. > > But were there other issues, also? > > Thank you, > > -- > Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
