bug#36079: unhelpful error message

[Mark H Weaver]

Hi Ricardo and Robert,

Ricardo Wurmus <address@hidden> writes:

>> Working on Guix, I encountered the following:
>>
>> Within a guix checkout, I edited gnu/packages/haskell.scm, accidentally
>> making a Haskell comment:
>>
>>     (arguments
>>      `(#:tests? #f)) -- sporadic failure: 
>> https://github.com/fpco/streaming-commons/issues/49
>>
>> Then I tried to keep working on my in-development package, and was able to 
>> trace
>> the `guix build` error back to the following:
>>
>> $ ./pre-inst-env guild compile ../modules/postgrest.scm
>> ;;; note: source file /home/rob/guix/gnu/packages/haskell.scm
>> ;;;       newer than compiled /home/rob/guix/gnu/packages/haskell.go
>> ;;; note: source file /home/rob/guix/gnu/packages/haskell.scm
>> ;;;       newer than compiled 
>> /run/current-system/profile/lib/guile/2.2/site-ccache/gnu/packages/haskell.go
>> ice-9/boot-9.scm:752:25: In procedure dispatch-exception:
>> Syntax error:
>> unknown location: package: invalid field specifier in form —-
>
> This error is produced by the “package” macro, which is of this form:
>
>   (package
>    (field value)
>    (another-field its-value)
>    …)
>
> The macro has a number of valid field names and it tries to do some
> simple validation.  That’s where the error comes from.  When “--” is
> encountered it is in the position of a field, so the macro tries to be
> helpful and reports that “--” is not a valid way to specify a field.
>
> This error message is not produced by Guile.

Well, yes and no.  It is true that code in Guix is calling
'syntax-violation' to report the error.  However, it is also true that
Guix passes to 'syntax-violation' the syntax object corresponding to
“--”, which ideally should have source location information attached to
it.  If the syntax object in question represented a list or some other
heap-allocated value, it *would* have had source location information
attached, and that would have been included in the error message.

This issue is a longstanding limitation in Guile's source location
tracking.  The problem is that Guile uses Scheme's standard 'read'
procedure to read the source code, which uses plain Scheme symbols to
represent identifiers.  Scheme symbols with the same name are
indistinguishable, i.e. every occurrence of 'x' or '--' is represented
by precisely the same heap object, and therefore there's no way to
attach source information to each occurrence of a symbol.

Fixing this would involve abandoning Scheme's standard 'read' procedure
for reading source code, and instead using a different reader (not yet
written) that uses a different object type to represent identifiers and
immediate values.  Our macro expander would need to be modified to
support this new representation.

I believe this should be done, and I hope to find the energy to do it
some day.

       Mark