Ticket #1082 (closed defect: notabug)

Opened 12 months ago

Last modified 12 months ago

wrong *print-circle* handling by format directive ~:*

Reported by: avodonosov Owned by:
Priority: normal Milestone:
Component: ANSI CL Compliance Version: trunk
Keywords: format *print-circle* Cc: avodonosov

Description

Use case:

(setf *print-circle* t)
(format nil "~{~A ~:*~A, ~}" '("77" "88"))
=> "#1=77 #1#, #2=88 #2#, "

Expected value

=> "77 77, 88 88, "

Change History

comment:1 Changed 12 months ago by gb

See  http://clozure.com/pipermail/openmcl-devel/2012-January/013303.html

If you can find something in the spec that justifies your claim that what you say is expected should be expected, I'd be glad to hear it.

Implementations differ in their handling of this case. Allegro CL (as of 9.0) and CCL (at least) generate similar output; other implementations generate what you expect. I don't know of any language in the spec that makes either behavior more correct than the other. As I said, I'd be glad to be made aware of such language.

comment:2 Changed 12 months ago by avodonosov

I reported this because it was very suprising to me - there is no circularity in this structure, and #1# is not aestetic, IMHO.

BTW, I've reduced the use case to

(format nil "~A ~:*~A" "77")
 => "#1=77 #1#"

I might be wrong. My job is to report suspicious issue. Feel free to close the ticket if you think it is correct.

For my code I just use workaround: (let ((*print-circle* nil)) (format ... ))

comment:3 Changed 12 months ago by gb

  • Status changed from new to closed
  • Resolution set to notabug

Note that the spec says that *PRINT-CIRCLE* controls attempts to detect structure sharing as well as circularity. It doesn't say anything (or doesn't seem to say enough) about the granularity at which that detection is attempted.

Note: See TracTickets for help on using tickets.