> HOWEVER, since the error message is available to user code, this would be a non-compatible change. We would need an outpouring of piteous entreaties before contemplating that.
I don't think parsing of error messages, and then especially the portion after the first line that includes a formatted copy of the calling/error code needs to be accessed, and if you did, you would run ;: on it to "sanitize" the code compartments... I don't think that is being done, or would risk breaking code that would prefer not support 903 than recoding those sections: If there were relying on an exact string match, perhaps relying on the exact :: parsing match would be a simple cross version compatible matching. J provides great error handling with :: , and with it's explicit control words. Needing a different action response, based on the context of where in the expression a domain error occurred is not done in J. Before, you parse error messages deeply while relying on precise format, you would explicitly guard inputs that can cause the alternate conditions. On Friday, December 10, 2021, 12:32:39 p.m. EST, Henry Rich <[email protected]> wrote: The user can't change the format of the error display. With an error you have to indicate where the error is, which JE does by inserting 3 spaces. That in turn means that the user's formatting must be destroyed. However, we could maybe put 1 space instead of 0 between primitives. I personally would find that easier to read. HOWEVER, since the error message is available to user code, this would be a non-compatible change. We would need an outpouring of piteous entreaties before contemplating that. Henry Rich On 12/10/2021 12:25 PM, Hauke Rehr wrote: > Maybe it is not the best default choice for form of display in errors? > The user can be blamed once she changes the form of display; > the default form shouldn’t be misleading but very explicit imo. > > Am 10.12.21 um 17:15 schrieb Henry Rich: >> Now that I look into it, the error display of } }: as }}: is correct, >> because the error display removes all unnecessary blanks and }}: is >> two words. >> >> A display that fools RE, Raul, and me has got to be considered >> misleading, but I don't see what to do about it except be ready for >> next time. >> >> Henry Rich >> >> On 12/10/2021 10:59 AM, Raul Miller wrote: >>> I was confused for a moment when you said "The linear display of ({:} >>> }:) is wrong." >>> >>> But then I saw that you meant the linear display of ({:} }) in the >>> error message for ({:} })t >>> >>> It can also be instructive to try that expression: >>> >>> 9!:3(5) >>> >>> ({:}}:) >>> {:} }: >>> >>> In other words, in the current version of J, at least, when there's no >>> opening {{ a }} pair is not treated as a delimiter. >>> >>> That's arguably for the best. (Though for old J hands, it also >>> suggests that smiley/frowny delimiters -- in other words (: ): -- >>> might have been more comfortable for us.) >>> >>> Thanks, >>> >> >> > -- This email has been checked for viruses by AVG. https://www.avg.com ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
