Raul wrote: > It's defined as having an empty domain -- > why not rely on the definition being > accurate?
Cap's raison d'etre is grammatical, not semantic. That it is a verb, and that its domain is defined to be empty, is incidental. I prefer for my code to recognize this, and not hinge on incidentals, or encourage others to do so. > I think of a raised error as a "violation of type" issue. I think we can agree that one of the guiding principles in the design of J is "graceful degradation"; witness, e.g., %. which has rank 2 but works "as expected" on vector and scalar arguments. There are innumerable other examples. I prefer to maintain this principle as far as I can, in my own J code. Of course, there always comes a tipping point, but one hopes to defer that as long as possible (or reasonable). -Dan -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Raul Miller Sent: Monday, July 23, 2012 4:44 PM To: [email protected] Subject: Re: [Jprogramming] cap On Mon, Jul 23, 2012 at 2:01 PM, Dan Bron <[email protected]> wrote: > I constrain my use of cap to the left tine of forks. I do not apply it as a > verb, because I don't like to rely on its domain(s) being empty. It's defined as having an empty domain -- why not rely on the definition being accurate? > Finally, allowing for errors to be raised is often the least desirable > design for a J program (J's array-oriented nature means a failure on a > single cell results in the failure of all cells, even if most or all but one > are perfectly well formed). I think of a raised error as a "violation of type" issue. If my code raises an error, the code which supplied the data is wrong. -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
