Hi Ludo, On Sun, 07 Nov 2021 at 23:14, Ludovic Courtès <l...@gnu.org> wrote:
> I believe commit 4d59596a1c5f6b20870e619cbf67068ac7dd64ff fixes it (the > issue affected ‘read-error’ exceptions for reasons other than missing > closing parentheses). With your fix, I am questioning the ’if’ test. Introduced before 524c9800afb433cc474132185d8e37f72004adb3. For instance, it reads, --8<---------------cut here---------------start------------->8--- /tmp/pkgs/foo.scm:26:1: missing closing parenthesis --8<---------------cut here---------------end--------------->8--- when Guile reports, --8<---------------cut here---------------start------------->8--- /tmp/foo.scm:25:1: unexpected end of input while searching for: ) --8<---------------cut here---------------end--------------->8--- and this message is parsed to catch and report the first message, instead. Well, I agree that on one hand, Guile error messages seem badly worded for newcomers. On the other hand, post 4d59596a1c5f6b20870e619cbf67068ac7dd64ff, the message for extra parenthesis, --8<---------------cut here---------------start------------->8--- guix repl: error: read error while loading '/tmp/pkgs/foo.scm': /tmp/pkgs/foo.scm:25:23: unexpected ")" --8<---------------cut here---------------end--------------->8--- is inconsistent from the one for missing parenthesis. Other said, the then-branch uses ’format’ and the else-branch uses ’report-error’. Some Guile errors are sometimes cryptic (the reason of “missing closing parenthesis” I guess), therefore, the question is: do we add ’cond’ branches for each cases? Using “report-error” for all? Or do we only rely on Guile error messages? Dropping ’if’ test. Last, checking and playing with all that, I note that this catch is done when using ’load*’ and nothing is done for option ’load-path’. Cheers, simon
