Poor source location tracking in backquote

Bug #1361502 reported by heller
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Fix Released

Bug Description

The new backquote reader produces less precise source location
information than the old. For instance this example

(block nil
  (handler-bind ((warning
    (lambda (c)
         (sb-c::find-error-context nil))))))
    (compile nil '(lambda () `(1 2 3 4 ,(progn (/ 1 0)))))))

returns (2 0) with the new reader and (1 5 2 0) with the old.
(1 5 2 0) is clearly better.

The reason for this is that the new reader creates a sb-impl::comma
structure for ,X while the old reader creates a list. Later, the
compiler walks this object in sb-c::sub-find-source-paths. The walk
descents down into lists but not into structs; so the compiler has
less precise source location information with the new reader.

sb-c::sub-find-source-paths could be improved by walking down the
comma struct, but I think a better solution is not to create those
comma structs in the first place and instead use a list representation
like (unquote X). Not only would lists produce better source location
information for SBCL itself, but also avoid some breakage in third
party code. It would also follow the suggestion in the spec:

  Implementors who have no particular reason to make one choice or
  another might wish to refer to IEEE Standard for the Scheme
  Programming Language, which identifies a popular choice of
  representation for such expressions that might provide useful to be
  useful compatibility for some user communities.


Revision history for this message
Douglas Katzman (dougk) wrote :

Source location tracking will be the easier thing to fix than to re-re-implement backquote.

In Common Lisp we have the luxury of altering the pretty-printer, and such luxury makes the suggestion to follow Scheme somewhat naive, when Scheme does not (at least in the spec) provide for an extensible pretty-printer.

In CLISP, UNQUOTE is indeed a list, and consequently it is easy to create a list of data that by accident prints unreadably using only the builtin PPRINT-FILL, let alone user-written format-control strings.

Welcome to GNU CLISP 2.49 (2010-07-07) <http://clisp.cons.org/>
[1]> (pprint-fill *standard-output* ''(foo bar system::backquote x what))

The symbol WHAT has disappeared. This is not a jab at CLISP - it is an indicator of the difficulty in getting everything right, because as noted in the earlier discussions on sbcl-devel, CLISP is probably the only other open source implementation that gets as many things right as does the new SBCL implementation. (Not having also checked commercial implementations)

Revision history for this message
Stas Boukarev (stassats) wrote :

In 6f1e01e1a5b76ab0cf1c2f1c06c633389a64b0ce.

Changed in sbcl:
status: New → Fix Committed
Changed in sbcl:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers