_. will not be removed and will not be a spelling error. Aside from other issues that have been raised, there is the question of what to display when data does contain a NaN (from external sources). Answer? _. .
----- Original Message ----- From: Raul Miller <[EMAIL PROTECTED]> Date: Tuesday, March 18, 2008 8:36 Subject: Re: [Jprogramming] Handling NaN error with #:_ To: Programming forum <[email protected]> > On 3/18/08, Mark D. Niemiec <[EMAIL PROTECTED]> wrote: > > "Raul Miller" <[EMAIL PROTECTED]> wrote: > > > Wouldn't this make testing difficult? > > > > For test suites, one can still always hand-craft a NaN: > > [ nan =: 3!:2 a.{~225 0 0 0 8 0 0 0 1 0 0 0 0 0 0 > 0 0 0 0 0 0 0 248 255 > > _. > > > > However, it's much harder to create one inadvertently if one > can't spell it. > > It's much easier to weed out old code if a spelling error (or > similar)> is signalled (much like how x. y. u. v. m. n. were > changed in 6.01) > > This motivation seems contrary to the design of J. > > For example, I can already type 2+3. when I meant to type 2+.3 > > More generally, when working with mathematics, it has generally > been important that I check my work. And getting rid of _. > would not change that. > > I have seen many languages introduce mechanisms which make > lesser used forms take more typing than other expressions, but > in the general case longer more round-about code does not > equate to correct code. It just means that you have to figure > out what has gone wrong in something rather verbose. > > Put differently, this sounds like a solution looking for a problem. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
