(Moving to chat forum since this is no longer about writing J code.)
I guess we do not retain sufficient parsing information to report the
relevant position on the offending line for error reporting that looks
like a parsing report.
Instead, we might report the name of the primitive that threw the error?
Here, we would update the definitions for DF1 and DF2 so that they
save the identity of the current primitive on the J stack, define a
global "current error primitive" which is normally null, and change
jt->jerr would take the most local current primitive identity and
update that "current error primitive". Then error reporting would
look up the name of the primitive that threw the error and replace it
with the primitive's token (and, optionally, valence and/or type
information which might be gleaned from the C name).
Here, the big work would be building the lookup table to be used for
error reporting. Basically, I guess, this would be generating a string
which would be used as a line by itself after the | domain error (or
whatever) line.
(Also some minor work to suppress that kind of error reporting when
it's a syntax or spelling error.)
Looking at the current implementation:
jsrc$ egrep '\<D[FX][12]\>' *.c | grep -v define | sed
's/.*D[FX][12][(]//; s/[,)].*//' | sort -u | wc -l
282
... this table would have almost 300 entries, so this would not be a
small effort. Though I have not studied all of the new code and it may
be that some uses of DF1/DF2 do not correspond to specific primitives
but instead define words which are only used in parsing (and, thus,
their entries in this table could be trivial).
A larger cost would be that someone should build tests to throw at
least one example of each error. (And the three existing uses of eftx
in the J tests might also need attention,)
A "hidden benefit", though, would be that this kind of cross reference
concept might be extended further (with C comments, perhaps) to help
orient people working on the engine...
So.. not something that we could whip out in a day. But this approach
should at least be straightforward enough that implementation should
eventually be possible. (Unlike my suggestion that we could use the
parsing error approach.)
Thanks,
--
Raul
On Fri, Dec 10, 2021 at 12:45 PM Henry Rich <[email protected]> wrote:
>
> Unfortunately not every primitive is executed (when special code
> executes a combination /en bloc/). In cases where the primitive is
> executed, its original word number is not available if the primitive is
> inside a compound.
>
> The best the code can do is report the verb that failed. That might be
> a fork, as it is here.
>
> Carrying the word number through to the error message might barely be
> possible but it would be a big rewrite. Something to consider.
>
> Henry Rich
>
> On 12/10/2021 12:32 PM, Raul Miller wrote:
> > If we are considering enhancing the error display, I would focus on
> > making obvious the specific primitive which threw the error. (In this
> > case, that would be the {: primitive.)
> >
> > Compare:
> >
> > ({:}}:)t
> > |domain error
> > | ({:}}:)t
> > ({:.}}:)t
> > |spelling error
> > | ({:.}}:)t
> > | ^
> >
> > 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
