Hi Ricardo and Robert, Ricardo Wurmus <rek...@elephly.net> 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
